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OPINION 


A  SYSTEMATIC  APPROACH 
TO  PRIORITIZING 
WEAPON  SYSTEM  REQUIREMENTS 
AND  MILITARY  OPERATIONS 
THROUGH  REQUISITE  VARIETY 


MAJ  Douglas  B.  Bushey,  USA,  and  Dr.  Mark  E.  Nissen 


The  21st  century  U.S.  military— being  redesigned,  developed  and  tested 
today — is  driven  by  diverse  global  mission  requirements  and  force 
modernization  subject  to  fiscal  constraint.  The  practical  application  of  the  theory 
of  requisite  variety  is  accomplished  through  development  of  an  analytical 
framework  for  prioritizing  force  structure  elements.  It  provides  a  systematic 
basis  for  assigning  priority  to  research,  development,  production,  and 
operational  activities.  Requisite  variety  ensures  warfighting  effectiveness  subject 
to  a  variety  of  different  mission  requirements  and  budget  constraints.  The 
authors  use  a  game-theoretic  model  to  emphasize  the  importance  of  requisite 
variety  in  weapon  system  prioritization  and  operational  decision  making.  They 
outline,  define,  and  provide  examples  of  three  concrete  approaches  to 
increasing  the  variety  available  to  a  military  commander— regulation, 
information,  and  variety  catalysts.  And  they  reinforce  the  distinction  between 
qualitative  and  quantitative  variety  in  military  systems  and  operations.  They 
further  examine  the  framework  through  an  Army  advanced  warfighting 
experiment,  which  leads  to  important  results  and  considerations  with  respect 
to  requirements  determination,  weapon  system  prioritization,  and  battlefield 
operations. 


As  it  heads  into  the  21st  century,  the 
U.S.  military  is  driven  by  two  di¬ 
vergent  factors  (Figure  1):  diverse 
global  mission  requirements,  and  force 
modernization  subject  to  fiscal  constraint. 


Regarding  the  first  factor,  the  military 
continues  to  fulfill  mission  requirements 
around  the  world,  and  it  must  remain  pre¬ 
pared  to  deploy,  in  force,  literally  at  a 
moment’s  notice.  Although  there  is  no 
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•  Mission  requirements 

•  Fiscal  constraints 

•  Multiple  conflicts 

1 

♦  Competition  for  $$ 

•  OOTW 

•  Politics  of  weapon 
system  prioritization 

I  Decision  Framework  for 

|  Optimizing  Force  Structure 

Figure  1.  Motivation  for  the  Study 


longer  a  single,  galvanizing  threat  such  as 
the  former  Soviet  Union,  we  observe  an 
increasing  likelihood  of  forces  deploying 
to  multiple,  simultaneous  regional  con¬ 
flicts.  Missions  are  expanding  to  include 
operations  other  than  war  (OOTW),  which 
can  require  a  different  set  of  skills  and 
assets  than  those  designed  and  used  for 
intensive  conflict.  For  example,  the  strict 
rules  of  engagement  for  peacekeeping 
missions  could  require  a  unique  set  of  riot 
control  weapons.  A  former  Service  Sec¬ 
retary  has  commented  on  this  situation 
(West,  1997):  “In  the  past,  [we]  trained 
primarily  to  fight  and  win  large-scale  con¬ 
flicts;  now  we  must  prepare  to  meet  a 
wider  range  of  contingencies  at  all  levels 
of  the  operational  continuum.” 

The  result  is  that  U.S.  military  forces 
face  greater  demands  than  ever  before, 
across  a  wide  spectrum  of  threats  that  are 


globally  dispersed  yet  temporally  con¬ 
fined.  In  short,  the  requirements  have 
never  been  so  demanding  and  of  such  wide 
variety. 

Moreover,  existing  military  assets  are 
aging  and  require  modernization  to  catch  up 
with  the  quantum  technological  advances 
of  the  past  two  decades,  particularly  those 
involving  information  technology.  But 
modernization  of  a  responsive  global  force 
represents  an  expensive  proposition.  This 
expense  is  compounded  by  the  increased 
variety  of  the  expanding  military  mission 
noted  above.  Concurrent  with  diverse  and 
demanding  mission  requirements,  the 
United  States  faces  a  severe  fiscal  con¬ 
straint  and  has  significantly  decreased 
defense  spending.  Competition  for  dwin¬ 
dling  defense  dollars  is  intense,  as  mod¬ 
ernization  must  compete  with  readiness, 
armor  with  air  defense,  the  Army  with  the 


2 


Prioritizing  Weapon  System  Requirements  and  Military  Operations  through  Requisite  Variety 


Navy  and  Air  Force,  and  so  forth.  Further, 
the  politics  of  weapon  system  prioriti¬ 
zation  are  equally  intense.  As  a  result,  the 
risk  of  misallocating  scarce  military 
resources  to  the  wrong  mix  of  systems  has 
never  been  greater.  The  potential  conse¬ 
quence  of  this  situation  is  clear;  when  the 
need  for  warfighting  arises,  the  correct 
mix  and  number  of  forces  may  not  be 
available  within  the  time  frame  required 
for  decisive  action. 

This  article  demonstrates  practical 
application  of  the  theory  of  requisite  vari¬ 
ety  through  the  development  of  a  decision 
framework  for  prioritizing  force  structure. 
Although  the  scope  of  this  article  is  quite 
broad  and  applicable  to  the  entire  joint 
warfighting  community,  we  make  the 
framework  and  associated  concepts  con¬ 
crete  by  focusing  on  the  Army,  which 
arguably  is  most  affected  by  expanding 
mission  requirements  such  as  OOTW.  We 
will  examine  the  current  requirements 
determination  process  and  conceptual  doc¬ 
trine  the  Army  proposes  to  use  in  the  21  st 
century.  With  this  background,  we  apply 
the  theory  of  requisite  variety  to  develop 
a  conceptual  framework  for  analyzing  the 
mix  of  weapon  systems  programs  and 
operational  forces.  The  framework  pro¬ 
vides  a  systematic  basis  for  prioritizing 
research,  development,  production,  and 
operational  activities  to  ensure  military 
warfighting  effectiveness  subject  to  a 
variety  of  different  mission  requirements 
(e.g.,  OOTW,  peacekeeping,  war)  and 
severe  budget  constraints.  We  then  exam¬ 
ine  the  model  by  assessing  this  conceptual 
framework  in  terms  of  an  Army  advanced 
warfighting  experiment,  and  then  present 
conclusions  and  recommendations  for  the 
military  leadership. 


Current  Requirements 
Determination  Process 


To  address  the  complexities  of  21  st  cen¬ 
tury  warfare,  the  Army  has  implemented 
a  new  requirements  determination  process 
and  developed  unique  concepts  for  land 
combat  called  Force  XXI  operations.  The 
new  requirements  determination  process 
investigates  many  promising  advances  in 
science  and  technology,  in  addition  to 
meeting  operational  deficiencies  identified 
through  mission  area  analysis.  The  pro¬ 
cess  depicted  in  Figure  2  begins  with  the 
training  and  doctrine  command 
(TRADOC)  vision,  which  is  translated 
into  required  future  operational  capabili¬ 
ties  (FOCs).  FOCs  are  intended  to  provide 
a  warfighting  focus  for  the  Army’s  science 
and  technology  investments.  One  set  of 
FOCs  is  written  for  each  of  the  Army’s 
battle  laboratories  and  encompasses  the 
battlefield  dynamics  for  which  each  lab  is 
responsible.  The  battle  labs  (along  with 
TRADOC  com- 

"To  address  the 
complexities  of  2 1st 
century  warfare,  the 
Army  has  imple¬ 
mented  a  new 
requirements 
determination 
process  and 
developed  unique 
concepts  for  land 
combat  called  Force 
XXI  operations." 


bat  developers) 
use  integrated 
concept  teams 
(ICTs)  to  trans¬ 
form  FOCs  into 
solutions  across 
the  domains  of 
doctrine,  train- 1 
ing,  leader  de¬ 
velopment,  or¬ 
ganization,  ma¬ 


teriel,  and  per¬ 
sonnel.  These  solutions  are  examined  and 
tested  through  live,  virtual,  and  concep¬ 
tual  warfighting  experiments.  Feedback 
from  the  experiments  is  used  to  further 
define  and  refine  the  product  until  a  firm 
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Figure  2 .  Army's  Requirements  Determination  Process 


requirement  emerges  (U.S.  Army  Plans  for  Force  XXI  operations  make 
TRADOC,  1996).  As  noted  above,  the  numerous  direct  and  indirect  references  to 

number  and  diversity  of  such  firm  and  the  need  for  variety  in  our  forces.  For 

well-understood  requirements  continues  example,  they  call  for  knowledge-based 

to  multiply.  operations,  which  exploit  information 

The  requirements  determination  pro-  technology  and  leverage  other  technologi- 

cess  is  designed  to  be  flexible.  ICTs  cal  opportunities  to  achieve  a  new  level 

include  personnel  from  a  broad  spectrum  of  effectiveness  in  joint  warfighting,  while 

of  disciplines  and  have  the  potential  to  minimizing  exposure  to  casualties.  They 

facilitate  a  smooth  transition  to  the  inte-  also  call  for  soldiers  themselves  to  become 

grated  product  teams  (IPTs)  used  to  man-  more  versatile,  capable  of  performing  a 

age  materiel  programs.  But  the  resources  number  of  different  missions,  often  simul- 

needed  to  purchase  all  materiel  require-  taneously.  They  emphasize  multidimen- 

ments  are  rarely  there — especially  in  the  sional  operations — attacking  the  enemy 

quantities  specified  by  commanders.  The  across  myriad  spectra,  decisive  operations, 

result  is  that  key  doctrine  and  tactics  and  even,  simultaneously,  humanitarian 

deemed  necessary  cannot  be  fulfilled.  We  relief.  Such  features  require  commanders 

believe  there  are  numerous  opportunities  on  the  ground  to  be  equipped  with  a  wide 

to  leverage  the  theory  of  requisite  variety  variety  of  diverse  weapon  systems  and 

during  this  process  to  help  solve  the  modem  assets,  not  just  a  large  number  of 

problem.  existing  ones. 
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Unfortunately,  the  military  has  not 
articulated  this  need  for  variety  well,  and 
it  has  consequently  suffered  considerable 
criticism.  For  example,  Army  Force  XXI 
operations  have  been  criticized  by  some 
who  believe  the  conceptual  doctrine  is  too 
abstract,  at  the  level  of  “Star  Wars,”  and 
the  Army  has  not  adequately  explained  its 
vision  for  warfighting  experiments  to 
Congress  (General  Accounting  Office, 
1995).  The  theory  of  requisite  variety  pro¬ 
vides  the  kind  of  intellectual  foundation 
and  approach  to  effectively  articulate  this 
need,  as  well  as  to  assign  priority  to,  quan¬ 
tify,  and  justify  its  integrated  weapon  sys¬ 
tems,  modernization  plans,  tactics,  and 
doctrine. 

Requisite  Variety 


The  theory  of  requisite  variety  was 
developed  through  studies  of  complex 


system  dynamics  (Ashby,  1956).  Re¬ 
searchers  such  as  Ashby  observed  that  as 
systems  become  more  complex,  the  vari¬ 
ety  of  their  behaviors  proliferates.  Further, 
in  order  to  control  a  complex  system,  the 
variety  of  responses  built  into  the  control 
mechanism  must  be  at  least  equal  to  the 
variety  of  the  system  itself.  In  other  words, 
the  variety  of  the  controller  must  equal  or 
exceed  that  of  the  controlled,  and  the 
degree  of  variety  sufficient  to  control  a 
particular  system  is  defined  as  requisite 
variety.  Following  Ashby  (p.  208),  only 
variety  can  control  variety. 

The  theory  of  requisite  variety  has  a 
direct  military  application.  For  example, 
it  directly  supports  the  Army  concept  of 
dominant  maneuver.  In  the  simple  case 
shown  in  Figure  3,1  the  friendly  com¬ 
mander  serves  as  the  control  mechanism 
and  the  “enemy”(situation)  represents  the 
system  to  be  controlled.  Examples  of  this 
structure  are  coalition  forces  seeking  to 


Figure  3.  System  Control 
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control  Iraq’s  access  to  weapons  of  mass 
destruction,  and  peacekeeping  forces 
working  to  control  ethnic  killing  in 
Bosnia.  Each  action  taken  by  the  enemy 
is  perceived  by  the  commander,  who  uses 
the  resources  and  options  available  to 
counter  such  actions  and  control  the  sys¬ 
tem.  As  the  enemy  grows  in  capability,  the 
variety  of  available  actions  proliferates.  To 
control  this  increasingly  capable  enemy, 
as  a  minimum,  the  commander  must  at 
least  be  able  to  counter  enemy  actions.  But 
to  dominate  the  enemy,  the  commander 
requires  a  variety  of  weapons  and  tactics 
that  exceeds  the  enemy’s  ability  to  make 
an  effective,  timely  response. 

We  illustrate  requisite  variety  in  a  game- 
theoretic  context  as  shown  in  Table  1. 
Although  this  example  is  simple,  the 
theory  and  practical  application  scale  very 
well  to  support  military  planning  and 
weapon  system  prioritization  up  to  the 
Army  level  and  beyond  (e.g.,  the  Depart¬ 
ment  of  Defense,  the  North  Atlantic  Treaty 
Organization,  coalition  forces).  The 
friendly  commander’s  courses  of  action 
(COAs)  are  listed  on  the  left  side  of  the 
table.  In  this  example,  they  include  an 
armor  battalion  (AR  BN),  an  attack  heli¬ 
copter  battalion  (ATK  HEL),  and  an  air 
defense  task  force  (AD  TF)  capable  of 
defeating  helicopters  and  tactical  ballistic 


missiles.  The  enemy  commander’s  COAs 
are  listed  along  the  top.  They  include  an 
attack  helicopter  squadron  (ATK  HEL),  a 
tank  regiment  (TK  REG),  a  motorized  rifle 
regiment  (MR  REG),  and  a  tactical 
ballistic  missile  regiment  (TBM).  As  noted 
above,  there  is  no  hard  limit  to  the  num¬ 
ber  of  COAs  and  mix  of  participants  (e.g., 
Army/Navy,  U.S. /foreign  military,  war/ 
OOTW)  that  can  be  analyzed  through  this 
technique.  We  now  describe  the  simulated 
battle  or  engagement  outlined  in  Table  1 . 

Both  commanders  are  assumed  to  be 
situationally  aware  (i.e.,  they  can  see  the 
table)  and  the  game-theoretic  rules  are  as 
follows.  The  enemy  is  allowed  to  make 
the  first  move  by  selecting  a  COA,  and 
thus,  a  particular  column.  The  friendly 
commander,  observing  this  selection,  then 
chooses  a  COA  in  response  (i.e.,  a  par¬ 
ticular  row).  Recent  military  experience 
is  replete  with  examples  of  this  “wait  for 
the  enemy  to  move”  approach  (e.g.,  Iraq 
invades  Kuwait;  Serbia  seizes  control  of 
Bosnia).  The  outcome  of  the  encounter  is 
determined  by  the  intersection  of  the 
selected  row  and  column  and  is  repre¬ 
sented  in  the  table  by  bold,  italic  letters. 
Let’s  say,  for  example,  that  if  the  outcome 
is  a,  the  friendly  commander  wins  the 
engagement.  If  it  is  not  a ,  the  friendly 
commander  loses.2  Clearly  the  specific 


Table  1.  Matrix  Model  1  of  Ashby's  Law 


ATK 

TK 

MR 

HEL 

REG 

REG 

TBM 

AR  BN 

b 

a 

c 

d 

ATK  HEL 

c 

c 

a 

b 

AD  TF 

a 

b 

b 

a 
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table  entries  would  vary  for  each  theater 
of  war  or  operations. 

It  is  straightforward  to  show  in  Table  1 
that  the  friendly  commander  possesses 
requisite  variety  to  control  the  enemy.  If 
the  enemy  moves  first  with  attack  helicop¬ 
ters  (ATK  HEL),  for  example,  the  friendly 
commander  can  counter  with  his  air  de¬ 
fense  task  force  (AD  TF).  Similarly,  if  the 
enemy  moves  first  with  a  tank  regiment 
(TK  REG),  for  example,  the  friendly  com¬ 
mander  can  counter  with  armor  ( AR  BN), 
and  so  forth.  Regardless  of  the  enemy 
CO  A,  the  friendly  commander  possesses 
sufficient  variety  to  choose  a  COA  and 
force  the  outcome  to  become  a  (therefore 
he  can  win),  regardless  of  the  enemy  COA 
selected.  And  recall  that  the  friendly  com¬ 
mander  even  allows  the  enemy  to  move 
first.  Thus,  the  friendly  commander  can 
dominate  the  theater  because  he  possesses 
the  requisite  variety  of  forces  and  assets. 

At  first  glance,  this  military  application 
may  appear  obvious  or  even  simplistic.  A 
commander  might  state,  for  example,  “Of 
course  if  you  give  me  more  tanks  or  more 
soldiers  I  will  defeat  the  enemy;  I  will 
overpower  him  with  numerical  superior¬ 
ity.”  However,  a  careful  distinction  must 
be  made  between  numerical  superiority 
and  the  variety  of  options  available  to  a 
commander.  Numerical  superiority,  or 
quantitative  variety,  is  just  that — the  num¬ 
ber  of  soldiers,  number  of  weapon  systems 
or  other  factors  used  to  determine  a 
superior  force.  This  was  long  the  basis  of 
Soviet  weapon  systems  prioritization.  Par¬ 
ticularly  when  projecting  force  abroad, 
however,  numerical  superiority  cannot 
always  be  ensured. 

Alternatively,  the  nature  of  requisite 
variety  is  more  qualitative.  It  is  less  con¬ 
cerned  with  aggregate  totals  than  the  mix 


"Thus,  the  friendly 
commander  can 
dominate  the 
theater  because 
he  possesses  the 
requisite  variety  of 
forces  and  asset s." 


of  different  types  and  capabilities  of  sol¬ 
diers,  weapon  systems,  and  tactics,  as  well 
as  various  configurations  and  temporal 
patterns  in  which  they  can  be  employed. 
Thinking  back  to  the  Gulf  War,  for  ex¬ 
ample,  most  experts  seem  to  agree  that  sat¬ 
ellite  reconnaissance,  broadband  commu¬ 
nication,  fast  armored  maneuver,  and  Pa¬ 
triot  air  defense  proved  to  be  more  instru¬ 
mental  to  decisive  victory  than  the  num¬ 
ber  of  tanks  and 
soldiers  in  the¬ 
ater.  Indeed, 

Gulf  War  expe¬ 
rience  supports 
our  arguments 
by  suggesting 
that  the  com¬ 
mander  with  a 
sufficient  mix 

(i.e.,  requisite  variety)  of  CO  As  can  even 
defeat  an  enemy  with  numerical  superior¬ 
ity.3  This  point  is  further  illustrated 
through  the  simulated  battle  or  engage¬ 
ment  outlined  in  Table  2.  This  time  the 
friendly  commander  has  greater  numeri¬ 
cal  quantities  of  some  weapons  than  be¬ 
fore  (i.e.,  greater  quantitative  variety):  two 
armored  battalions  and  two  infantry  bat¬ 
talions.  However,  his  qualitative  variety 
has  actually  decreased  because  he  no 
longer  has  an  attack  helicopter  battalion 
or  air  defense  task  force.  Now  the  table 
shows  the  friendly  commander  can  no 
longer  control  the  situation  100  percent 
of  the  time.  For  instance,  the  enemy  can 
choose  two  COAs — attack  helicopters 
(ATK  HEL)  and  tactical  ballistic  missiles 
(TBM) — and  force  the  outcome  to  be 
something  other  than  a  (i.e.,  force  the 
friendly  commander  to  lose  the  engage¬ 
ment).  Despite  having  greater  numbers 
of  armor  and  infantry,  the  friendly 
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Table  2.  Matrix  Model  2 


ATK 

HEL 

TK 

REG 

MR 

REG 

TBM 

AR  BN 

b 

a 

c 

d 

AR  BN 

b 

a 

c 

d 

INF  BN 

c 

b 

a 

c 

INF  BN 

c 

b 

a 

c 

commander  lacks  the  requisite  variety  to 
counter  and  control  the  enemy. 

Clearly,  the  concept  can  subsume  Army 
operations  to  include  joint  warfare.  For 
example,  ADM  Joseph  Prueher,  Com- 
mander-in-Chief,  U.S.  Pacific  Command, 
recently  made  an  indirect  reference  to 
requisite  variety  (Prueher,  1996): 

...each  service  (Army,  Navy,  Air 
Force)  brings  a  unique  capability 
to  the  battlefield.  It  is  similar  to  a 
football  team.  You  can’t  have  a 
team  with  all  fast  receivers  with 
good  hands.  In  addition  you  need 
strong,  relatively  slow  linemen, 
defensive  specialists,  and  a  quar¬ 
terback.  This  is  the  nature  and 
strength  of  joint  warfare. 

With  this  background,  we  turn  to  the 
question  of  how  to  determine  requisite 
variety  for  a  military  force,  putting  the 
framework  to  practical  use. 

Applied  Military  Framework 

Our  scheme  to  operationalize  the  con¬ 
cept  of  requisite  variety  is  based  on  some 


concrete,  well-understood  methods  for 
increasing  commanders’  ability  to  domi¬ 
nate  the  enemy.  Consider  the  relatively 
simple  model  outlined  above,  in  which  a 
commander  is  responsible  for  controlling 
a  system.  Figure  4  shows  an  expanded 
model  of  the  system  embedded  in  its  en¬ 
vironment  (depicted  by  the  rectangle  that 
encompasses  the  situation).  This  rectangle 
is  drawn  with  dashed  lines  to  indicate  that, 
in  real  life,  the  environment  is  fluid,  rather 
than  static.  Highlighted  in  the  model  are 
three  factors  affecting  a  commander’s 
variety  of  action:  regulation,  information, 
and  variety  catalysts. 

Regulation 

External  factors  exert  forces  on  the  sys¬ 
tem  beyond  the  commander’s  control,  and 
regulation  can  affect  variety  either  posi¬ 
tively  or  negatively.  On  the  positive  side, 
regulation  (beyond  the  commander’s  con¬ 
trol)  can  be  used  to  limit  the  capabilities 
of  current  enemies  or  potential  threats. 
International  treaties  (e.g.,  Strategic  Arms 
Limitation  Treaty,  Nuclear  Non-Prolifera¬ 
tion  Treaty),  postwar  disarmament  (e.g., 
of  Germany  and  Japan)  and  arms-inspec- 
tion  programs  (e.g.,  in  Iraq)  represent 
examples  of  positive  regulation.  Notice 


8 


Prioritizing  Weapon  System  Requirements  and  Military  Operations  through  Requisite  Variety 


the  subtlety  of  such  regulation.  It  serves 
to  augment  the  commander’s  variety,  not 
by  increasing  his  COAs,  but  by  decreas¬ 
ing  the  variety  required  for  him  to  control 
the  enemy. 

As  noted  above,  the  opposite,  negative 
effect  of  regulation  occurs  when  the 
commander’s  mission  portfolio  is 
expanded  (e.g.,  to  include  OOTW).  These 
effects  actually  increase  complexity  and 
therefore  exacerbate  the  need  for  variety 
in  the  friendly  system.  So  long  as  the 
United  States  continues  to  use  military 
forces  to  counter  natural  disasters  and 
conduct  OOTW,  such  lack  of  system  regu¬ 
lation  increases  the  variety  of  missions  the 
Army  has  to  perform. 


Information 

Information  can  be  used  by  the  com¬ 
mander  to  reduce  the  uncertainty  of  a  sys¬ 
tem.  Figure  4  shows  numerous  enemy 
COAs  flowing  toward  the  commander.  To 
begin  an  engagement,  the  enemy  selects 
one  of  these  COAs.4  But  until  the  com¬ 
mander  can  see  or  sense  which  COA  is 
selected,  he  must  consider  and  plan  for 
every  likely  option  available  to  the  enemy. 
For  example,  the  commander  in  theater 
must  deal  with  the  uncertainty  of  when, 
where,  and  how  (even  if)  an  enemy  might 
strike.  Shown  as  a  funnel  in  Figure  4, 
information  acts  as  a  filter  to  reduce  un¬ 
certainty  (e.g.,  sensing  enemy  armor 
movements)  and  to  expedite  the  proactive 


Figure  4.  Framework  for  Providing  Requisite  Variety 
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use  of  counter  actions  available  to  the 
commander  (e.g.,  long-range  air  mobile 
strikes).  Indeed,  such  information  domi¬ 
nance  represents  a  key  aspect  of  Force 
XXI  operations. 

Information  also  benefits  the  units  and 
soldiers  that  are  led  by  the  commander. 
Some  call  this  the  “fog  of  war.”  To  the 
soldier  on  the  ground,  it  is  the  confusion 
or  uncertainty  of  where  he  is  on  the 
ground,  where  the  other  units  are  located, 
and  what  is  happening  on  the  battlefield. 
Information — situational  awareness — on 
the  digital  battlefield  reduces  this  uncer¬ 
tainty,  informing  soldiers  where  they  are, 
where  their  buddies  are,  and  where  the 
enemy  is. 

It  is  important  to  understand,  however, 
that  information  does  not  reduce  or  limit 
the  enemy’s  CO  As.  Rather,  it  reduces  the 
uncertainty  of  the  situation  and  helps  the 

commander  to 
anticipate  and 
counter  them 
responsively. 
This  analysis 
points  to  com¬ 
mand,  control, 
communica¬ 
tion,  and  intel¬ 
ligence  (C3I) 
assets  as  principal  tools  to  exploit  infor¬ 
mation  dominance.  Integrated  C3I  assets 
reduce  the  time  it  takes  to  observe  the 
enemy,  orient  friendly  forces,  and  decide 
what  action  to  take,  for  example. 


"Information  also 
benefits  the  units 
and  soldiers  that 
are  led  by  the 
commander.  Some 
call  this  the  'fog 
of  war.'" 


Variety  Catalysts 

The  analysis  above  also  points  to  mo¬ 
bility  assets,  which  complement  informa¬ 
tion  by  reducing  the  time  required  to  take 
action.  As  with  information,  mobility  has 
no  direct  effect  on  enemy  CO  As,  but  by 


increasing  mobility,  the  commander’s 
COAs  (i.e.,  variety)  increase.  Thus,  the 
reader  should  appreciate  that  relative 
variety  is  key  to  this  analysis.  Moreover, 
mobility  represents  an  example  of  the 
most  potent  dimension  associated  with  this 
framework:  variety  catalysts.  As  depicted 
in  Figure  4,  variety  catalysts  directly 
increase  the  number  of  COAs  available 
to  the  commander.  They  include  changes 
in  doctrine,  training,  organizations,  lead¬ 
ership,  personnel  and  materiel.  Figure  4 
shows  a  set  of  COAs  flowing  from  the 
commander  to  the  enemy.  Variety  cata¬ 
lysts,  depicted  as  a  magnifying  glass, 
amplify  the  number  and  types  of  COAs 
and  increase  the  commander’s  variety. 
As  noted  above  concerning  materiel 
solutions,  there  are  two  ways  to  catalyze 
variety:  quantitatively  and  qualitatively. 

Quantitative  catalysts.  Increasing 
quantitative  variety  means  increasing  the 
number  of  the  same  types  of  weapon 
systems,  soldiers,  or  units.  This  method 
relies  on  massive  force  structures  to  over¬ 
whelm  the  enemy.  It  is  not  concerned  with 
different  types  or  kinds  of  weapon 
systems,  but  entirely  with  the  quantities 
of  each.  By  increasing  the  number  of 
weapon  systems,  variety  expands  due  to 
the  increased  number  of  combinations 
available  to  the  commander.  Consider 
ADM  Prueher’s  football  analogy  from 
above.  Quantitative  variety  is  like  a  team 
fielding  22  players  against  the  opponent’s 
1 1 .  Think  of  all  the  different  combinations 
of  pass  routes  available  to  the  quarterback 
with  nine  wide  receivers,  for  example. 

While  this  time-tested  focus  on  quan¬ 
titative  variety  may  appear  attractive,  it 
has  two  distinct  disadvantages.  The  first 
is  cost.  In  today’s  environment,  the  DoD 
has  little  chance  for  budget  increases. 
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Rather,  military  commanders  are  now  ac¬ 
customed  to  making  do  with  less.  Even 
so,  opportunities  to  increase  quantitative 
variety  are  not  limited  to  just  “buying 
more  stuff.”  Most  notably  in  the  combat 
service  support  domain,  the  effective  num¬ 
ber  of  weapon  systems  (e.g.,  measured  by 
tactical  aircraft  sortie  rates)  can  be 
increased  by  reducing  repair  time, 
decreasing  mean  time  to  repair,  and  simi¬ 
lar  logistical  interventions.  The  second 
disadvantage  is  that  numerical  superior¬ 
ity  does  not  directly  translate  to  victory 
on  the  battlefield.  Earlier  we  saw  that 
the  friendly  commander,  despite  having 
superior  numbers,  could  not  completely 
dominate  the  engagement  because  he 
lacked  the  necessary  attack  helicopters  and 
air  defense  assets.  In  many  instances,  qual¬ 
ity,  not  quantity,  is  the  dominant  factor  in 
theater. 

Qualitative  catalysts.  Qualitative 
variety  concerns  the  diversity  of  actions 
available  to  control  the  system  (e.g.,  com¬ 
mander  CO  As).  Returning  to  our  football 
analogy,  to  increase  qualitative  variety,  a 
team  could  recruit  players  with  different 
skills.  Some  may  be  fast  runners  and  catch 
well,  while  others  are  big,  strong,  and  very 
effective  on  the  line,  with  still  others  who 
may  kick  well,  and  so  forth.  Note  also  by 
analogy  that  modem-era  strategies  and 
play  selections  require  all  players  to  be 
smart  and  well-trained.  The  Denver 
Broncos  won  Superbowl  XXXII  despite 
having  a  relatively  “small”  offensive  line, 
for  example,  in  part  because  of  the  variety 
of  effective  plays  it  could  execute.  A 
different  option  is  to  recruit  players  that 
are  multitalented,  athletes  able  to  play 
multiple  positions  and  roles  well  (e.g., 
running  backs  who  can  throw  passes, 
blocking  receivers,  quarterbacks  able  to 


run).  Such  multitalented  players  tend  to 
be  quite  expensive,  however. 

Regarding  military  weapon  systems, 
there  are  three  primary  approaches  to  in¬ 
creasing  qualitative  variety.  The  traditional 
approach  is  to  build  many  different  types 
of  weapon  sys¬ 
tems  (e.g.,  ser-  -  ’ 

"The  use  eff  current 
vice-unique  air-  and  deve|  , 

craft  or  trucks).  space  technologies. 
This  is  analo-  for  example,  opens 
gous  to  recruit-  up  an  entirely  new 
ing  specialist  set  of  options  for  the 
players  with  commander  who  can 
different  skills,  sense  and  observe 
The  use  of  cur-  from  the  ultimate 
rent  and  devel-  'high  ground/" 
oping  space 

technologies,  for  example,  opens  up  an  en¬ 
tirely  new  set  of  options  for  the  com¬ 
mander  who  can  sense  and  observe  from 
the  ultimate  “high  ground.”  History 
shows  that  the  disadvantage  of  this 
option  is  cost.  Different,  specialized 
weapon  systems  require  unique  invento¬ 
ries  of  spares,  separately  trained  mechan¬ 
ics,  idiosyncratic  ammunition,  and  spe¬ 
cialized  operator  skills,  the  life-cycle  cost 
of  which  is  relatively  high. 

A  second  approach — adapted  from 
commercial  industry — is  to  design  fami¬ 
lies  of  weapon  systems.  For  instance,  a 
Bradley  chassis  can  be  used  not  only  for 
an  infantry  fighting  vehicle,  but  also  for 
an  air  defense  artillery  system,  and  the 
Army  currently  does  this  with  the  family 
of  medium  tactical  vehicles,  which  share 
a  common  chassis  but  are  available  in 
different  cargo  variants  (e.g.,  materiel 
handling,  dump,  tractor,  wrecker,  vans). 
Likewise,  the  Navy  envisions  its  next 
generation  of  surface  combatants  (SC-21) 
in  terms  of  a  family  of  ships,  much  C3I 
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software  is  now  developed  into  product 
lines,  and  so  forth.  Each  individual  sys¬ 
tem  in  a  family  or  product  line  has  a  mix 
of  common  and  peculiar  elements  in  this 
approach.  But  this  approach  also  suffers 
some  of  the  same  limitations,  in  that 
specialized  parts,  mechanics,  operators, 
and  the  like  could  be  required  for  each 
peculiar  portion  in  a  system  family  or 
product  line. 

A  third  approach  to  increasing  qualita- 


cost  and  two-thirds  of  the  problems.”  He 
continues  (Augustine,  1983): 

Soon  DoD  will  build  an  aircraft 
that  is  so  expensive  that  it  will 
have  to  be  shared  by  the  Services. 

The  Air  Force  will  use  it  for  three 
days,  the  Navy  for  two,  and  the 
Army  and  Marines  will  use  it  half 
the  time  for  the  other  two  days  of 
the  week. 


tive  variety  is  through  weapon  systems 
capable  of  performing  multiple  missions. 
This  is  similar  to  recruiting  a  multitalented 
player.  For  example,  one  weapon  super¬ 
system  could  be  developed  not  only  to 
shoot  artillery  fire,  but  also  to  destroy  en¬ 
emy  aircraft  and 


"A  f bird  approach 
to  increasing  quali¬ 
tative  variety  is 
through  weapon 
systems  capable  of 
performing  multiple 
missions/' 


have  enough 
mobility  and  di¬ 
rect  firepower 
to  be  used  as  an 
infantry  fight¬ 
ing  vehicle. 
This  third  ap¬ 


proach  differs 


from  that  above 


in  that  both  the  air-defense  and  infantry 
missions,  for  example,  are  accomplished 
by  the  same  vehicle,  whereas  two  simi- 
lar-but-different  vehicles  (sharing  com¬ 
mon  parts)  are  required  in  the  family  or 
product-line  scheme  above.  This  option 
also  has  disadvantages,  for  building  com¬ 
plex  weapon  systems  with  multiple  roles 
is  difficult  and  sometimes  costly.  Not  only 


Another  disadvantage  is  the  risk  that 
one  of  these  super  systems  would  be 
destroyed.  One  artillery  round  or  even  a 
simple  software  virus  could  knock  out  a 
considerable  amount  of  firepower.  It 
would  be  like  our  multitalented  football 
player  suffering  an  injury  which  prevents 
him  from  playing. 

Other  areas  such  as  doctrine,  organiza¬ 
tions,  training,  and  recruiting  can  also 
increase  the  qualitative  variety  of  a  mili¬ 
tary  force.  While  they  may  not  directly 
increase  the  number  of  CO  As  available 
to  the  commander,  they  magnify  variety 
by  enabling  a  commander  to  more  effi¬ 
ciently  use  his  resources.  Continuing  our 
football  analogy,  these  latter  areas  would 
pertain  more  to  the  coaching  staff,  train¬ 
ing  facilities,  and  draft  strategies  than  the 
football  players  themselves,  but  in  a  bud¬ 
get-constrained  environment  such  as  that 
faced  by  the  DoD,  one  is  compelled  to 
investigate  every  viable  opportunity, 
particularly  those  that  increase  variety  at 


does  operation  near  the  edge  of  the  state  reasonable  cost, 
of  the  art  often  greatly  increase  cost  and 


performance  risk,  it  can  also  have  a  del- 

eterious  effect  on  reliability.  Norm  Augus-  EXAMINATION  OF  THE  FRAMEWORK 


tine  described  this  as  the  Law  of  Insatiable 

Appetites:  “The  last  10  percent  of  the  per-  We  have  used  the  applied  military 
formance  sought  generates  one-third  of  the  framework  to  articulate  three  concrete 
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methods  for  increasing  the  commander’s 
ability  to  dominate  the  battlefield:  regu¬ 
lation,  information,  and  variety  catalysts. 
Clearly,  all  three  alternatives  can  be  com¬ 
bined  to  compound  synergistic  effects,  but 
the  optimal  mix  is  dependent  on  the 
specific  set  of  requirements  (e.g.,  war  or 
OOTW,  desert  or  jungle,  pre-positioning 
or  amphibious  assault)  and  subject  to 
budgetary  constraints.  This  applied  mili¬ 
tary  framework  provides  the  analytical 
structure  to  objectively  conduct  the 
necessary  requirements  and  tradeoff 
analyses. 

The  framework  is  examined  by  apply¬ 
ing  it  to  an  Army  advanced  warfighting 
experiment  (AWE).  The  intent  is  to  ana¬ 
lyze  the  exercise  from  the  perspective  of 
our  requisite  variety  framework.  The 
exercise,  conducted  from  July  to  Decem¬ 
ber  1995,  was  a  general  officer  working 
group  project  sponsored  by  TRADOC. 
The  goal  of  the  exercise  was  to  determine 
Force  XXI  requirements,  structure,  and 
conceptual  doctrine  for  use  in  follow-on 
live  and  virtual  exercises.  We  chose  this 
particular  exercise  because  it  served  as  the 
foundation  for  many  TRADOC  Force  XXI 
conceptual  doctrine  publications  and  re¬ 
search  studies.  The  objective  of  the  exer¬ 
cise  was  to  build  upon  the  early  Force  XXI 
concepts  and  produce: 

•  the  division  operations  and  organiza¬ 
tion  manual  for  Force  XXI  units; 

•  the  warfighting  tasks  and  tactics,  tech¬ 
niques,  and  procedures  (TIP)  for  Force 
XXI  units;  and 

•  the  how-to-fight  manual  for  the 
experimental  force  (EXFOR5). 


i# 


the  general 
officer  working 
group  recognized 
that  without  requi¬ 
site  variety,  the 
Force  XXI  division 
would  be  unable  to 
conduct  decisive 
operations;  that  is, 
the  division  would 
not  be  able  to 
dominate  the 
battlefield/' 


A  major  regional  contingency  set  in  the 
21  st  century  served  as  the  scenario  for  this 
exercise.  The  friendly  forces  consisted  of 
a  Force  XXI  division  (e.g.,  Ml  A2  tanks, 
M2A3  infantry  fighting  vehicles,  LOSAT 
antitank  systems,  future  scout  vehicles 
(FSV),  and  Comanche  helicopters).  This 
notional  division  was  assigned  the 
dominant  mis¬ 
sion  of  the 
corps’  decisive 
operation.  The 
opposing  forces 
consisted  of  a 
combination  of 
high-  and  me¬ 
dium-technol¬ 
ogy  enemy  divi¬ 
sions  (e.g.,T72/ 

T80  tanks,  BTR 
80  infantry  ve¬ 
hicles,  HIND 
D/E/F  helicop¬ 
ters).  It  is  interesting  to  note  the  opposing 
forces  outnumbered  the  Force  XXI  divi¬ 
sion;  that  is,  the  “enemy”  possessed 
superior  quantitative  variety. 

The  AWE  supports  many  aspects  of  our 
conceptual  framework.  For  example,  the 
general  officer  working  group  recognized 
that  without  requisite  variety,  the  Force 
XXI  division  would  be  unable  to  conduct 
decisive  operations;  that  is,  the  division 
would  not  be  able  to  dominate  the  battle¬ 
field.  The  lack  of  requisite  variety  in  this 
exercise  can  be  traced  to  two  factors.  First, 
using  TRADOC  vernacular,  the  Force 
XXI  division  did  not  have  the  “assured 
capabilities”  required  for  the  operation. 
Two  examples  involve  mobility  assets  for 
the  light  brigade  and  air  defense  assets. 
The  ideal  plan  of  attack  included  the  use 
of  light  infantry  in  combination  with  armor 


13 


Acquisition  Review  Quarterly — Winter  1999 


forces.  But  the  division  lacked  the  airlift 
or  truck  capability  needed  to  fully  exploit 
this  option.  The  resulting  mobility  differ¬ 
ential  made  it  difficult  to  synchronize 
infantry  with  armor  and  left  infantrymen 
vulnerable  to  counter-attacks  with  no 
capability  for  self-extraction.  In  addition, 
the  extended  range  of  the  operation  left 
the  division  vulnerable  to  air  attacks  and 
surveillance.  Because  the  Force  XXI 
division  lacked  sufficient  air-defense 
assets,  the  enemy  could  exploit  this  weak¬ 
ness.  In  other  words,  if  the  enemy  chose 
this  COA,  the  friendly  commander  did  not 
have  the  requisite  variety  to  control  the 
situation. 

Second,  the  corps  operation  plan  pre¬ 
scribed  tasks  that  limited  how  the  25th 
(Force  XXI)  Division  intended  to  fight. 
For  example: 

•  Corps  planned  fire  strikes  on  the 
enemy’s  15th  Tank  Division  (TD)  and 
3rd  Motorized  Rifle  Division  (MRD) 
prior  to  the  25th  Division  contact  with 
the  enemy. 

•  Corps  employed  dynamic  obstacles  to 
fix  the  enemy’s  15TD  and  3MRD. 

•  Corps  assigned  an  aviation  brigade  to 
attack  the  lead  regiments  of  the 
enemy’s  15TD  and  3MRD. 

This  regulation  from  higher  headquar¬ 
ters  limited  the  options  available  to  the 
friendly  commander,  because  these 
actions  were  in  his  area  of  operations.  The 
examples  show  that  external  regulation, 
in  this  case,  reduced  the  number  of  CO  As 
available  to  the  friendly  commander  (i.e., 
reduced  his  qualitative  variety).  Our 
framework  suggests  that  less  (negative) 


regulation  could  reduce  this  effect. 
Further,  (positive)  regulation  could  reduce 
the  complexity  of  missions  the  friendly 
commander  is  required  to  perform, 
thereby  decreasing  the  variety  of  the  situ¬ 
ation  to  be  controlled.  For  example,  higher 
headquarters  could  have  reduced  the  threat 
of  enemy  second-echelon  divisions  by 
conducting  air  strikes  beyond  the  25th 
Division’s  area  of  operations.  The  group 
of  general  officers  deemed  this  point  to 
be  very  significant;  one  of  their  key  find¬ 
ings  was  that  higher  headquarters  must 
reduce  the  prescriptive  tasks  dictated  to 
subordinate  units. 

This  examination  of  the  AWE  supports 
two  important  aspects  of  our  framework. 
First,  variety  in  the  friendly  force  is 
important.  Without  requisite  variety,  for 
example,  the  25th  Division  could  not  con¬ 
duct  decisive  operations.  Second,  higher 
command  levels  must  consider  the  impact 
of  external  factors  and  strive  to  regulate 
these  factors.  Constraining  commanders 
on  the  ground,  for  example,  can  actually 
limit  warfighting  effectiveness. 

Given  these  observations,  one  might 
surmise  the  25th  Division  had  an  unsuc¬ 
cessful  day  on  the  battlefield,  but  this  was 
not  the  case.  The  division  was  highly  suc¬ 
cessful  because  of  the  information  avail¬ 
able.  The  general  officer  working  group 
realized  that  information  dominance  was 
a  valued  commodity  that  had  to  be  planned 
for  and  efficiently  used  to  be  effective. 
Integrated  C3I  assets  such  as  satellites, 
human  intelligence,  electronic  warfare, 
and  radar  systems  reduce  the  uncertainty 
of  the  enemy  situation.  This  situational 
awareness  was  leveraged  through  the  use 
of  highly  mobile  assets  (e.g.,  helicopters 
given  quick  attack  missions)  and  long- 
range  precision  strikes  to  proactively 
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shape  the  battlefield  and  dominate  the 
enemy.  They  attacked  the  enemy  in 
numerous  directions  from  dispersed  loca¬ 
tions.  By  integrating  C3I  and  mobility 
assets,  the  general  officers  achieved  syn¬ 
ergistic  results.  These  assets  allowed  the 
25th  Division  to  attack  in  a  variety  of 
patterns  by  leveraging  information. 

In  summary,  the  AWE  involved  all  three 
aspects  of  our  framework  for  providing 
requisite  variety:  regulation,  information, 
and  variety  catalysts.  This  helps  portray 
how  the  concepts  associated  with  requi¬ 
site  variety  and  our  analytical  framework 
can  be  applied  directly  to  the  military,  and 
it  highlights  key  elements  of  their  use  and 
utility  in  support  of  Army  experiments 
involving  its  ideas  for  warfare  in  the 
future:  Force  XXI.  This  examination  of 
the  framework  also  reinforces  the  distinc¬ 
tion  between  qualitative  and  quantitative 
variety  and  shows  how  even  a  numerically 
inferior  force  can  prevail  using  regulation, 
information,  and  variety  catalysts  from  the 
framework.  In  essence,  we  see  that  variety 
can  serve  as  a  proxy  for  military  efficacy 
and  provide  some  capability  for  explana¬ 
tion  and  prediction  of  differential  results 
on  the  battlefield.  Thus,  our  framework  for 
requisite  variety  provides  a  language  of 
constructs  and  method  of  analysis  for 
robust  and  detailed  effectiveness  studies. 
And  when  combined  with  the  many  cur¬ 
rent  techniques  for  cost  analysis,  this 
framework  supports  a  novel,  systematic 
approach  to  prioritizing  weapon  system 
requirements  and  military  operations 
through  requisite  variety. 


Conclusions 


The  analytical  framework  we  have 
introduced  supports  a  systematic  approach 
to  prioritizing  weapon  system  require¬ 
ments  and  military  operations  through 
requisite  variety.  This  framework  takes 
Ashby’s  Law,  a  relatively  simple  but 
underused  theory,  and  applies  it  directly 
to  the  military.  It  shows  that  complex  sys¬ 
tems,  including  battles  and  engagements, 
can  be  evaluated  through  requisite  vari¬ 
ety,  and  the  frame¬ 


"The  analytical 
framework  we 
have  introduced 
supports  a  system¬ 
atic  approach  to 
prioritizing  weapon 
system  requirements 
and  military 
operations  through 
requisite  variety/7 


work  provides  ana¬ 
lytical  constructs 
and  guidelines  for 
using  variety  as  a 
proxy  for,  or  predic¬ 
tor  of,  military  effi¬ 
cacy.  The  military 
can  first  use  the 
framework  as  a  di¬ 
agnostic  tool  to  ana¬ 
lyze  the  variety  of 

the  system.  For  example,  it  can  help  assess 
what  threats  are  to  be  faced  and  the  diver¬ 
sity  of  missions  that  are  to  be  performed, 
then  help  identify  possible  solutions  using 
the  framework  to  maximize  the  opera¬ 
tional  effectiveness  of  forces  through  the 
requisite  variety  construct.  Cost  can  then 
be  weighed  against  the  possible  solutions. 

Further,  the  framework  provides  a  com¬ 
mon  vocabulary  to  explain  weapon 
requirements  and  the  concepts  of  Force 
XXI  to  both  Congress  and  the  warfighters 
on  the  ground.  It  helps  to  answer  many 
important  and  timely  questions.  For 
example,  why  is  the  military  spending  mil¬ 
lions  of  dollars  on  high-tech  equipment 
to  digitize  the  battlefield?  Why  is  the  Army 
developing  conceptual  doctrine  that  seems 
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more  suitable  for  Luke  Skywalker  than 
Sergeant  York?  Our  use  of  requisite  vari¬ 
ety  can  improve  the  quality  of  answers 
provided  to  Congress,  the  soldiers,  and 
other  concerned  stakeholders. 

Although  the  concept  of  variety  may 
appear  intangible,  the  analytical  frame¬ 
work  described  in  this  paper  outlines  three 
concrete  approaches  to  increasing  com¬ 
manders’  variety  for  battlefield  domina¬ 
tion:  regulation,  information,  and  variety 
catalysts.  Each  of  these  has  distinct  ad¬ 
vantages  and 
"Our  use  of  disadvantages, 

requisite  variety  Optimally,  a 

can  improve  the  combination  of 

quality  of  answers  the  three  alter- 

provided  to  natives  should 

Congress,  the  be  considered 

soldiers,  and  for  their  syner- 

other  concerned  gistic  effects, 

stakeholders.'  and  when  cost 

is  combined 
with  variety  (as  a  proxy  for  effectiveness) 
in  the  equation,  this  framework  provides 
the  analytical  structure  necessary  to  ob¬ 
jectively  prioritize  weapon  systems  and 
evaluate  military  operations. 

Recommendations  for  the  Military 

This  work  leads  us  to  six  recommen¬ 
dations  for  the  military. 

Incorporate  variety  as  a  factor.  The 
most  significant  finding  of  this  study  is 
that  variety  can  be  a  useful  factor  for 
prioritizing  requirements  for  the  future 
operational  forces  of  the  U.S.  military.  We 
have  seen  that  future  military  forces  face 
a  diversity  of  threats  and  missions  in  a 
global  environment  with  unprecedented 
complexities.  The  theory  of  requisite 
variety  reveals  that  in  order  to  control  such 
complex  systems,  the  amount  of  variety 


in  the  control  mechanism  must  equal  or 
exceed  that  of  the  system  being  controlled. 
We  recommend  that  each  military  service 
move  to  directly  apply  variety  constructs 
such  as  regulation,  information,  and  vari¬ 
ety  catalysts  in  its  requirements  determi¬ 
nation  process  (especially  during  mission 
area  analysis  and  analysis  of  alternatives). 
TRADOC  should  combine  variety  with 
cost  as  primary  factors  for  prioritizing 
alternative  weapon  systems  and  force 
structures.  All  stakeholders  including 
ICTs,  IPTs,  battle  labs,  and  warfighters 
need  to  understand  the  concept  of  requisite 
variety. 

Aggressively  pursue  intelligence  on 
future  threats.  During  the  Cold  War,  the 
United  States  had  very  robust  intelligence 
efforts  to  gain  and  interpret  information 
about  the  Soviet  Union.  However,  as  defense 
spending  has  dwindled,  so  have  these  intel¬ 
ligence  efforts.  The  United  States  should 
continue  to  pursue  robust  intelligence 
efforts  focused  on  determining  valid 
threats.  Just  as  situational  awareness 
decreases  the  uncertainty  of  the  enemy 
situation  to  the  friendly  commander  on  the 
ground,  identifying  strategic  threats  can 
reduce  the  uncertainty  at  the  national  level. 
Without  these  intelligence  efforts,  it  will 
be  difficult  to  measure  the  amount  of 
variety  we  need.  The  potential  conse¬ 
quence  is  not  having  the  correct  mix  of 
forces  on  the  future  battlefield. 

Prioritize  weapon  systems.  Given 
current  financial  constraints,  the  short¬ 
term  military  requirements  should  focus 
on  C3I  and  mobility  systems.  Such  assets 
appear  to  provide  the  best  variety-to-cost 
ratio  and  may  represent  a  requisite-vari¬ 
ety  bridge  to  21st  century  warfare.  As 
illustrated  in  the  AWE,  information 
reduces  uncertainty  in  the  system,  and 
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mobility  complements  situational  aware¬ 
ness  to  increase  the  variety  of  action  for 
friendly  forces.  Modernization  of  other 
weapon  systems,  such  as  multirole  fight¬ 
ing  vehicles,  can  further  increase  force 
variety,  but  this  approach  portends  to  be 
quite  costly.  With  the  quality  of  intelli¬ 
gence  assets  that  exist,  the  military  can 
make  great  strides  by  simply  re-engineer¬ 
ing  the  process  of  obtaining  and  distribut¬ 
ing  information.  Notice  we  do  not  argue 
for  building  all  intelligence  systems  and 
no  action  systems.  But  neither  should  we 
neglect  intelligence  to  support  weapon 
system  modernization.  Either  way,  by  put¬ 
ting  all  our  eggs  in  one  basket,  we  risk 
not  having  the  requisite  variety  to  conduct 
decisive  operations. 

Continue  joint  warfare.  Using  the 
capabilities  of  all  the  Services  in  joint  war¬ 
fare  is  an  excellent,  low-cost  approach  to 
increasing  variety.  The  United  States 
should  continue  to  train  and  fight  as  a  joint 
team,  and  efforts  should  be  made  to 
increase  the  connectivity  of  weapon  sys¬ 
tems  and  doctrine  to  achieve  synergistic 
results  with  the  expanding  NATO  and 
potential  coalition  partners.  The  variety  of 
weapon  systems  in  current  inventories  and 
arsenals  of  allied  nations  is  substantial,  and 
it  augments  our  ability  to  attack  and 
defend  across  multiple  dimensions  from 
either  dispersed  or  close-proximity 
locations  on  the  battlefield. 

Reduce  higher  headquarters*  pre¬ 
scriptive  tasks  to  subordinate  units. 
Prescriptive  tasks  from  higher  headquar¬ 
ters  negatively  regulate  commanders  on 


the  ground  and  limit  their  warfighting 
effectiveness.  We  observed  this  phenom¬ 
enon  with  the  25th  Force  XXI  Division. 
Following  the  technique  of  empowerment, 
higher  headquarters  should  focus  on  what 
the  requirements  are,  not  how  to  perform 
them,  and  explicitly  decide  whether  and 
how  much  to  limit  commanders’  variety 
in  theater. 

Continue  variety  research.  Our  final 
recommendation  is  to  continue  this  line 
of  research  to  enhance  and  refine  the 
framework  developed  in  this  paper. 
Toward  this  end,  four  topics  for  further 
study  appear  to  have  merit: 

•  Investigate  alternatives  to  model  and 
quantify  the  factor  of  requisite  variety. 

•  Examine  what  impact  requisite  variety 
has  on  logistics  in  terms  of  life-cycle 
costs,  schedule,  and  performance. 

•  Research  different  possibilities  for 
variety  catalysts. 

•  Explore  how  the  conceptual  framework 
for  providing  requisite  variety  can  be 
applied  to  a  weapon  system  program. 

Research  represents  a  prudent  approach 
to  developing  new  knowledge — especially 
when  compared  to  trial  and  error  on  the 
battlefield — and  the  application  of  requi¬ 
site  variety  to  weapon  system  priori¬ 
tization  appears  to  be  a  timely,  practical, 
and  powerful  topic  for  continued  work 
along  these  lines. 
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Endnotes 


1 .  In  order  to  simplify  the  system,  we  as¬ 
sume  all  the  influences  on  the  enemy 
are  channeled  through  a  single  input 
and  all  effects  are  channeled  into  a 
single  output. 

2.  A  “win”  in  this  example  is  defined  as 
a  clear  and  decisive  victory.  All  other 
outcomes  result  in  a  loss.  The  various 
loss  outcomes  are  represented  in 
Tables  1  and  2  as  b,  c,  and  d. 

3.  Clearly,  many  factors  contributed  to 
success  in  the  Gulf  War  (e.g.,  air 
strikes,  tactical  skill  and  savvy  of 
commanders).  Indeed,  the  presence  of 
such  a  variety  of  factors  strengthens 
the  importance  of  our  distinction 
between  qualitative  and  quantitative 
variety. 


4.  Practically,  the  framework  and  analy¬ 
sis  can  scale  to  address  any  number 
of  simultaneous  enemy  CO  As. 

5 .  The  EXFOR  is  a  Force  XXI-equipped 
division  located  at  Fort  Hood,  TX.  The 
EXFOR  is  the  unit  that  participates  in 
the  “digital”  National  Training  Cen¬ 
ter  rotations  and  other  AWEs  to  test 
new  concepts  and  equipment. 
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OPINION 


THE  USAF  PEO/DAC/MAD 
STRUCTURE: 
SUCCESSFUL  PATTERN 
FOR  FUTURE  WEAPON 
SYSTEM  ACQUISITION? 

If  Co/  Charles  W.  Pinner,  USAF 


Among  the  acquisition  streamlining  initiatives  of  the  past  decade  was  the 
creation  of  the  program  executive  officer  position  to  oversee  the  execution  of 
a  portfolio  of  related  major  programs.  This  officer,  in  the  direct  reporting  chain 
between  the  program  manager  and  the  service  acquisition  executive,  has 
improved  and  focused  program  oversight  and  execution.  But  the  imposed 
insertion  of  this  position  into  the  existing  Air  Force  acquisition  structure  has 
complicated  the  relative  roles  and  responsibilities  with  other  acquisition 
officials— specifically,  the  mission  area  directors  and  the  designated  acquisition 
commanders— and  has  had  mixed  results. 


With  defense  acquisition  costs  in 
the  1 980s  exceeding  $  1 1 5  bil¬ 
lion  annually  and  amounting 
to  more  than  40  percent  of  the  defense 
budget  (Secretary  of  Defense,  1993),  it 
was  only  appropriate  that  the  Department 
of  Defense  (DoD)  and  Congress  focus  on 
various  acquisition  streamlining  and  re¬ 
form  initiatives.  In  1986,  the  Packard 
Commission  identified  numerous  short¬ 
comings  in  the  acquisition  process  and  rec¬ 
ommended  several  improvements.  These 


recommendations  became  the  goals  of 
subsequent  legislation,  Presidential  direc¬ 
tives  and  DoD  regulations.  The  result  of 
these  actions  was  a  major  restructuring 
of  how  the  Office  of  the  Secretary  of 
Defense  (OSD)  and  the  services  conduct 
acquisition  activities. 

One  significant  change  was  the  creation 
of  the  position  of  program  executive 
officer  (PEO):  a  corporate  operating 
official  who  would  supervise  a  portfolio 
of  mission-related  major  and  selected 
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programs  and  be  accountable  to  the  ser¬ 
vice  acquisition  executive  (S AE).  This  line 
officer,  in  the  direct  reporting  chain 
between  the  program  manager  (PM)  and 
the  S  AE,  would  streamline  and  focus  the 
activities  associated  with  executing  and 
overseeing  these  programs.  In  spite  of  the 
many  benefits  this  new  position  offered, 
its  imposed  insertion  into  an  existing 
organizational  structure  complicated  the 
relative  roles  and  responsibilities  of  other 
acquisition  officials,  specifically  (in  the 
Air  Force  [AF])  the  designated  acquisi¬ 
tion  commanders  (DACs)  and  the  mission 
area  directors  (MADs). 

This  research  project  (carried  out  for  the 
Industrial  College  of  the  Armed  Forces), 
evaluates  the  Air  Force  PEO/D AC/MAD 
acquisition  structure  in  terms  of  these 
relationships  to  assess  its  contribution  to 
the  goals  of  the  Packard  Commission.  To 
address  this  subject,  I  will  first  discuss  the 
background  of  the  creation  of  the  PEO 
position,  then  focus  on  the  overall  Air 
Force  weapon  system  acquisition  struc¬ 
ture,  with  emphasis  on  the  roles  and 
responsibilities  of  the  PEOs,  DACs,  and 
MADs.  Third,  I  will  discuss  the  issues  that 
arise  in  implementing  the  details  of  this 
structure  and  how  they  might  affect  the 
overall  performance  of  the  Air  Force 
acquisition  community.  Finally,  I  will 
present  some  of  the  options  that  may  im¬ 
prove  the  effectiveness  of  this  structure. 
Because  the  PEO  concept  represents  the 
newest  addition  to  a  relatively  well-estab¬ 
lished  structure,  I  will  present  this  evalu¬ 
ation  primarily  from  the  PEO  perspective 
and  use  the  description  of  the  DAC  and 
MAD  roles  to  frame  the  discussion. 


Methodology _ _ 

This  research  project  is  the  result  of  a 
literature  search  and  interviews.  Literature 
sources  included  official  reports,  briefings, 
directives,  and  memoranda;  informal  topic 
and  offsite  materials;  and  magazine  and 
newspaper  articles.  Individuals  inter¬ 
viewed  included  selected  present  and 
former  members  in  the  PEO/D  AC/MAD 
acquisition  structure. 

Background 


Packard  Commission 

In  response  to  public  criticisms  of  sen¬ 
sationalized  cost  overruns,  faulty  weapon 
system  performance,  and  perceived  con¬ 
tractor  fraud,  the  Reagan  administration 
appointed  David  Packard,  former  Deputy 
Secretary  of  Defense,  to  lead  the  Blue- 
Ribbon  Commission  on  Defense  Manage¬ 
ment  (commonly  referred  to  as  the 
Packard  Commission).  This  body  evalu¬ 
ated  defense  acquisition,  organization,  and 
decision-making,  Congressional  over¬ 
sight,  and  the  national  command  structure 
Reeves,  1996).  Its  major  task  was  to 
determine  if  the  implementation  of  private 
sector  methodologies  could  improve 
defense  management  business  practices 
(Santo-Donato,  1991,  p.  3). 

The  Commission  reported  that  cost, 
schedule,  and  performance  problems  in 
weapon  system  development  and  procure¬ 
ment  were  attributable  to  an  encumbered 
and  unproductive  acquisition  management 
system.  This  system  lacked,  among  other 
things,  “(1)  clear  accountability  for  acqui¬ 
sition  execution  and  (2)  unambiguous 
lines  of  authority  for  individuals  with 
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program  management  responsibilities” 
(General  Accounting  Office  (GAO),  1990, 
p.  1 ).  Another  assessment  was  that  the  pro¬ 
gram  manager’s  effectiveness  in  execut¬ 
ing  his  program  suffered  from  the  exces¬ 
sive  time  and  effort  spent  on  preparing 
reports  and  briefings  (Brooks,  1991 ,  p.  3). 

The  Commission  report  made  some  key 
recommendations  to  rectify  observed 
structural  and  procedural  weaknesses  in 
DoD  acquisition  management.  One  was 
that  each  service  should  institute  a  three¬ 
tiered  structure  for  all  major  defense  pro¬ 
grams.  This  structure  would  consist  of  an 
SAE,1  responsible  for  all  acquisition  mat¬ 
ters;  PEOs,  individually  responsible  for  a 
limited  group  of  major  programs;  and  pro¬ 
gram  managers,2  responsible  to  the  PEO 
for  all  program-related  matters  (GAO,  1 990, 
p.  1).  Further,  to  achieve  more  efficient  and 
effective  management,  this  acquisition 
structure  should  revise  its  practices  and 
procedures  to  emulate  the  characteristics 
of  most  successful  commercial  and 
government  projects.  Among  these 
characteristics  are: 

•  clear  command  channels — clear  align¬ 
ment  of  responsibility  and  authority, 
preserved  and  promoted  through  short, 
unambiguous  chains  of  command  to 
the  most  senior  decision  makers; 

•  program  stability — a  stable  environ¬ 
ment  of  funding  and  management, 
predicated  on  an  agreed  baseline  for 
cost,  schedule,  and  performance; 

•  limited  reporting  requirements — 
adherence  to  the  principle  of  “manage¬ 
ment  by  exception,”  and  methods  of 
ensuring  accountability  that  focus  on 
deviations  from  the  agreed  baseline; 


•  small,  high-quality  staffs — reliance  on 
small  staffs  of  specially  trained  and 
highly  motivated  personnel; 

•  communication  with  users — sound 
understanding  of  user  needs  achieved 
early  on  and  reflecting  a  proper  balance 
among  cost,  schedule,  and  performance 
considerations;  and 

•  better  system  development — includ¬ 
ing  aggressive  use  of  prototyping  and 
testing  to  identify  and  remedy  prob¬ 
lems  well  before  production,  invest¬ 
ment  in  a  strong  technology  base  that 
emphasizes  lower  cost  approaches  to 
building  capable  weapon  systems, 
greater  reliance  on  commercial  prod¬ 
ucts,  and  increased  use  of  commer¬ 
cial-style  competition  (Cheney, 
1989;  U.S.  President’s  Blue  Ribbon 
Commission,  1986;  Reeves,  1996). 

The  Packard  Commission  submitted  its 
final  report  in  June  1986.  President  Ronald 
Reagan  implemented  its  recommendations 
in  National  Security  Decision  Directive 
(NSDD)  219(1986). 

Legislative  Influence 

Two  contemporary  laws  also  played  a  role 
in  establishing  this  new  acquisition  struc¬ 
ture  for  DoD.  First,  the  Goldwater-Nichols 
DoD  Reorganization  Act  (Public  Law  99- 
433)  (1986)  sought  “to  reduce  the  bureau¬ 
cratic  layering  and  duplication  existing 
within  the  DoD  acquisition  process,  and 
to  produce  acquisition  programs  that 
would  better  meet  cost,  schedule,  and  per¬ 
formance  criteria”  (Santo-Donato,  1991). 
This  law  designated  within  OSD  the  (cur¬ 
rent)  position  of  Under  Secretary  of  Defense 
for  Acquisition  and  Technology — USD 
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(A&T)3 — while  the  second  law,  the  Na¬ 
tional  Defense  Authorization  Act  for  Fis¬ 
cal  Year  1987  Public  Law  99-961),  out¬ 
lined  his  duties,  responsibilities,  and  au¬ 
thority  (Brooks,  1991,  p.4). 

Unfortunately,  this  legislation  did  not 
achieve  the  desired  change  in  DoD.  Con¬ 
gress  and  other  organizations  external  to 
DoD  soon  began  to  criticize  the  Pentagon 

for  failing  to 
complete  the 
acquisition  re¬ 
forms  recom¬ 
mended  by  pre¬ 
vious  commis¬ 
sions  (Willis, 
1990).  Accord¬ 
ing  to  the  GAO 
report,  these 
criticisms  were 
based  on  the 
Services  affix¬ 
ing  the  new 
titles  to  existing 
positions  in  the 
old  structures, 
failing  to  em¬ 
power  the  PM- 
PEO-S AE 
chain  with  the  authority  and  control  in¬ 
tended,  and  failing  to  eliminate  the  unnec¬ 
essary  intermediate  management  layers 
(GAO,  1990,  p.  2). 


In  response  to 
criticisms.  President 
George  Bush 
directed  the 
Defense 
Management 
Review  (DMR)  in 
February  1989  to 
"review  DoD 
management  and 
develop  a  plan  to 
fully  implement  the 
Commission's 
recommendations, 
improve  the 
acquisition  process, 
and  more 

effectively  manage 
DoD  resources" 


DoD  Takes  Action 

In  response  to  criticisms,  President 
George  Bush  directed  the  Defense  Man¬ 
agement  Review  (DMR)  in  February  1989 
to  “review  DoD  management  and  develop 
a  plan  to  fully  implement  the  Com¬ 
mission’s  recommendations,  improve  the 
acquisition  process,  and  more  effectively 
manage  DoD  resources”  (GAO,  1990,  p.  2). 


By  December  1990,  the  GAO  reported 
that  the  Services  had  taken  action  to  revise 
their  acquisition  structures  to  comply  with 
the  Commission’s  intent.  What  remained 
was  DoD’s  updating  of  its  implementa¬ 
tion  guidance,  policies,  and  procedures  to 
reflect  the  DMR  changes. 

DoD  took  the  necessary  steps  in  the  follow¬ 
ing  months.  For  example,  DoD  Directive 
5000.1,  “Defense  Acquisition,”  DoD  In¬ 
struction  5000.2,  “Defense  Acquisition 
Management,  Policies  and  Procedures,”4 
and  DoD  Directive  5000.49,  “Defense  Ac¬ 
quisition  Board,”  all  address  the  role  of  the 
Defense  Acquisition  Executive  (DAE),  SAE, 
and  PEO  (Santo-Donato,  1991,  p.  16). 

DoD  asserted  that  the  implementation 
would  yield  improved  effectiveness  and 
cost  avoidance  in  weapon  system  acqui¬ 
sition,  with  projected  savings.  Secretary 
of  Defense  (SECDEF)  Richard  B.  Cheney 
stated  that  these  savings  would  be  applied 
to  readiness,  modernization,  maintaining 
force  structure,  and  improving  quality  of 
life  (Fulghum,  1990). 

Air  Force  Implementation  of  the  PiO 

In  response  to  the  1986  creation  of  the 
PEO  position  and  function,  the  Air  Force 
originally  attempted  to  use  its  existing 
acquisition  structure  to  accommodate  the 
requirements.  The  Air  Force  appointed  1 1 
PEOs,  most  of  who  were  product  division 
or  air  logistics  center  commanders.  These 
officers  served  dual-hatted  roles:  Keep  the 
Air  Force  acquisition  executive  (AFAE) 
apprised  of  program  status  and  report  to 
the  major  commands  (MAJCOM)  (Air 
Force  Systems  Command  [AFSC]  or  Air 
Force  Logistics  Command  [AFLC])  com¬ 
mander  on  their  control  of  program 
resources  and  major  program  decisions 
(Brooks,  1991,  p.  4). 
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The  1989  DMR  forced  greater  changes, 
however.  The  Air  Force  identified  six 
PEOs  (five  general  officers,  one  senior 
civilian  executive),  separate  from  the 
product  center  structures,  which  would 
have  no  other  responsibilities.  These  PEOs 
oversaw  key  weapons  systems  in  strate¬ 
gic,  information  systems,  tactical  and  air¬ 
lift,  space,  tactical  strike,  and  command, 
control,  and  communications.  According 
to  the  Secretary  of  the  Air  Force  (SEC  AF) 
Donald  Rice,  this  new  system  would  pro¬ 
vide  program  managers  with  greater 
autonomy,  responsibility,  accountability, 
and  time  to  focus  on  their  programs.  “The 
PEO  would  plan  corporate  strategies  and 
objectives,  and  serve  as  a  problem-solv¬ 
ing  team  leader  supported  by  the  systems 
and  logistics  commands.”  Center  com¬ 
manders  would  provide  support  (e.g., 
needed  experts,  test  and  research  facili¬ 
ties,  and  materials)  (Schmoll  and 
Cochrane,  1996). 

Thus,  legislation,  regulations,  and  di¬ 
rectives  have  crafted  the  structure  DoD 
uses  today  to  develop  and  procure  weapon 
systems.  From  this  process,  the  Air  Force 
has  delineated  an  organization  for  plan¬ 
ning,  programming,  budgeting,  and 
executing  acquisition  programs.  This 
structure  is  still  viable  in  the  Air  Force, 
but  continues  to  evolve  with  time  as  lead¬ 
ership,  portfolios,  and  other  needs  dictate. 
Who  are  the  key  players  in  the  Air  Force 
acquisition  community,  and  what  are  their 
roles  and  responsibilities? 


Structure,  Roles,  ahd  Responsibilities 

Air  Force  Acquisition  Chain  of  Command 

Acquisition  Policy  Directive  63-1 
(August  31, 1993)  established  the  current 


Air  Force  acquisition  system  for  “provid¬ 
ing  new  and  improved  materiel  capabili¬ 
ties  in  response  to  validated  needs  and 
according  to  public  law,  appropriate 
instructions,  and  international  agree- 
ments”(Jaquish, 

1993).  It  pre-  .  . 

..  '  i  "Thus,  legislation, 

scribes  the  rcq-  ,nlio“  s#  0I|d 

uisne  stream-  direc|,ve#have 
lined  structure  crafted  the  structure 
DuD  uses  today  to 
develop  and  procure 
weapon  systems* 
From  this  process, 
the  Air  Force  has 
delineated  an  orga¬ 
nization  for  plan¬ 
ning,  programming, 
budgeting,  and 
executing  acquisition 
programs* 


(see  Figure  l)in 
which  no  more 
than  two  levels 
of  review  exist 
between  the 
program  man¬ 
ager  and  the 
Milestone  Deci- 
sion  Authority 
(MDA).  Thus, 


## 


depending  on 
the  dollar  value, 

risk  level,  and  importance  of  the  program, 
the  program  manager  reports  through 
either  the  DAC,  PEO,  or,  under  special 
circumstances,  directly  to  the  AFAE.5 

This  new  system  effectively  took  the 
major  command  out  of  the  program  man¬ 
agement  chain.  HQ  Air  Force  major  com¬ 
mand  focus  lies  on  processes  and  resource 
management.  The  staff  is  less  involved  in 
program  management  oversight;  its  role 
is  supporting  the  acquisition  process  and 
providing  the  funding  and  human 
resources  the  program  manager  needs  to 
execute  his  program  (Brooks,  1991,  p.  17). 

The  AFAE,  who  is  also  the  Assistant 
Secretary  of  the  Air  Force  (Acquisition) 
( AS  AF[A]  or  S  AF/AQ),  is  responsible  for 
all  Air  Force  acquisition.  His  primary 
responsibilities  include  “establishing 
acquisition  policy,  supervising  and  evalu¬ 
ating  PEOs,  actively  participating  in  the 
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Figure  1.  AF  Acquisition  Structure 


biannual  planning,  programming,  and 
budgeting  system  (BPPBS)  process, 
representing  the  Air  Force  on  various 
acquisition  boards,  interfacing  with  Con¬ 
gress  and  overseeing  the  execution  of  all 
acquisition  programs”  (Brooks,  1991,  pp. 
10-1 1).6  Figure  2  shows  the  current  SAF / 
AQ  organization. 

PEO  Structure,  Roles,  and 
Responsibilities 

In  a  memorandum  forwarding  the  Air 
Force  progress  in  meeting  DMR  goals,  the 
SEC  AF  reiterated  that  “responsibility  and 
program  management  authority  flows 
directly  from  the  [AFAE]  to  the  PEOs  to 
program  managers  [of  major  and  selected 
acquisition  programs].  PEOs  will  have  no 
other  responsibilities  and  will  report  to  no 


one  on  program  management  outside  the 
SAE/PEO  chain”  (Rice,  1989).  The  PEO 
would  be  a  “senior  operating  official  with 
the  authority,  responsibility,  and  account¬ 
ability  for  a  portfolio  of  related  programs. 
The  PEO  is  to  be  a  planner  of  corporate  strat¬ 
egies  and  objectives,  a  problem-solving 
team  leader  supported  by  acquisition  com¬ 
mands”  (Rice,  1989).  The  PEO  is  a  line 
officer  responsible  and  accountable  to  the 
AFAE  for  the  cost,  schedule,  and  perfor¬ 
mance  (within  baseline)  of  the  portfolio.7 

The  PEO  exercises  authority  by:  issu¬ 
ing  program  direction  to  the  program 
manager,8  baselining  each  program  us¬ 
ing  the  acquisition  program  baseline 
process;  and  serving  as  the  direct  report¬ 
ing  official  for  the  program  manager.  The 
PEO  exercises  accountability  through 
monthly  acquisition  reports,  quarterly 
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Figure  2.  Current  SAF/AQ  Organization 


defense  acquisition  executive  summaries,  •  Be  deeply  involved  in  all  program 
breach  reporting,  and  direct  reporting  only  execution  matters, 
to  the  AFAE  (SAF/AQ  Management 

Workshop,  1995).  *  Provide  program  manager  wisdom, 

In  implementing  the  PEO  concept,  the  experience,  and  insight  into  Pentagon 
Air  Force  identified  the  following  daily  and  Washington  politics, 
responsibilities  of  the  PEO: 
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•  Screen  the  program  manager  from  the 
Pentagon. 

•  Be  the  “eyes  and  ears”  of  the  AFAE — 
no  surprises  and  make  it  happen. 

•  Work  with  infrastructure  managers  to 
ensure  support. 

•  Approve  program  resource  require¬ 
ments. 

•  Develop  (with  the  acquisition  strategy 
panel)  and  implement  acquisition 
strategy. 

•  Represent  portfolio  in  the  major 
reviews  process. 

•  Counsel  with  the  AFAE  and  MADs  on 
programming  and  budgeting  issues. 

•  Validate  System  Program  Office  (SPO) 
prepared  program  restructures  (‘what- 
if’  exercises). 

•  Review  all  program  documentation 
provided  to  the  Pentagon  and  the 
Congress. 

•  Approve  reprogramming  of  funds 
within  portfolio  (in/out)  in  the 
execution  year. 

•  Interface  with  users  during  program 
objective  memorandum  preparation. 

•  Assist  MADs  in  preparation  of  Air 
Force  budget. 

•  Assist  MADs  in  defense  of  the  budget 
with  OSD  and  the  Congress. 


•  Support  MADs  on  requirements  and 
requirements  reviews  (summits). 

•  Evaluate  program  managers. 

•  Monitor  the  “health”  of  the  program 
management  team  (Yates,  1990;  SAF/ 
AQ  Management  Workshop,  1995). 

However,  in  spite  of  the  general  duties 
and  functions  assigned,  refining  the  de¬ 
tails  of  the  PEO’s  role  and  responsibili¬ 
ties  often  falls  to  the  individual  PEO,  his 
interfaces,  and  occasionally  to  corporate 
vision. 

DAC  Structure,  Roles,  and 
Responsibilities 

The  same  AFAE  memorandum  that 
specifies  the  charter  for  the  PEOs  also 
identifies  the  responsibilities  of  the  DACs. 
The  product  divisions  and  air  logistics 
centers  commanders  of  Air  Force  Systems 
Command  and  Air  Force  Logistics  Com¬ 
mand  (forerunners  to  Air  Force  Material 
Command)  assume  the  role  of  DACs. 
They  perform  functions  similar  to  the 
PEOs.  Established  in  a  direct  reporting 
line  between  subordinate  program  man¬ 
agers  and  the  AFAE,  the  DACs  are  respon¬ 
sible  for  other  than  major  or  selected 
programs  (Welch,  1990).  However,  as 
center  commanders,  the  DACs  serve  an 
acquisition  support  role  as  well. 

A  SECAF  memorandum  on  October  2, 
1989,  reaffirmed  that  “the  AFSC  and 
AFLC  commanders  would  continue  to  be 
responsible  for  planning  all  required  sup¬ 
port  throughout  the  life  of  all  programs. 
These  commanders  [would]  recommend, 
for  [AFAE]  approval,  major  program 
assignments  to  a  PEO  and  coordinate  with 
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the  [AFAE]  on  other  program  assign¬ 
ments.”  They  would  be  directly  respon¬ 
sible  to  the  AFAE  for  support  to  PEOs  and 
program  managers.  The  quality  and  avail¬ 
ability  of  support  to  PEOs  and  program 
managers  would  ensure  that  SPO  staffs 
“remain  as  small  and  efficient  as  possible” 
(Rice,  1989). 

MAD  Structure,  Roles,  and 
Responsibilities 

The  MADs,  along  with  the  rest  of  SAFI 
AQ  acquisition  staff,  provide  the  AFAE 
with  the  broad  expertise  and  necessary 
functional  support  to  ensure  that  his  or  her 
“authority,  decisions,  and  management 
responsibilities  are  appropriately  pre¬ 
pared,  supported,  and  executed”  (Welch, 
1990).  They  also  facilitate  “the  continu¬ 
ous  interaction  and  dialogue  between  the 
AFAE,  the  PEOs,  and  DACs.”  Further, 
they  function  as  the  “focal  point  and  con¬ 
duit  for  all  interfaces  with  Congress,  OSD, 
JCS,  other  Services,  Air  Staff,  and 
MAJCOMs”  (Welch,  1990). 

The  MADs  “work  specific  operational, 
test,  technology,  and  developmental 
aspects  of  Air  Force  acquisition  for  other 
than  the  execution  year.  They  are  respon¬ 
sible  for  their  mission  area  planning, 
integration,  and  budget  process”  (Brooks, 
1991,  p.  12).  They  must  understand  the 
warfighter’s  needs  in  their  respective  mis¬ 
sion  areas  and  ensure  that  the  acquisition 
process  addresses  these  needs.  The  MADs 
authorize  programs  and  outline  the  respon¬ 
sibilities  of  the  key  players  through  the 
program  management  directive.  They  pro¬ 
vide  all  acquisition  inputs  to  the  BPPBS 
(e.g.,  program  objective  memoranda,  bud¬ 
get  estimate  summaries,  President’s  bud¬ 
get)  and  develop  the  program  budgets 
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within  the  Air  Force  Board  structure.  They 
also  identify  reprogramming  sources  for 
“top  down”  directed  requirements  (SAF/ 
AQ  Management  Workshop,  1995).  Table 
1  summarizes  the  basic  responsibilities  of 
the  PEOs,  DACs,  and  MADs. 

Thus,  laws,  regulations,  and  directives 
have  defined  the  general  structure,  roles, 
and  responsibilities  of  the  Air  Force 
acquisition  chain  from  the  DAE  down  to 
the  program  manager.  This  collective  body 
has  a  complex  multifaceted  challenge  to 
affordably  field  capable  weapon  systems 
to  meet  the  warfighter’s  needs.  The  struc¬ 
ture  that  accom¬ 
plishes  this  de¬ 
manding  task 
was  not  the  prod¬ 
uct  of  abottoms- 
up  approach,  but 
rather  evolved 
from  a  combina¬ 
tion  of  self-gen¬ 
erated  improve¬ 
ments  and  im¬ 
posed  modifica¬ 
tions.  While  these  identified  roles  and 
responsibilities  within  this  organizational 
structure  may  appear  to  be  clear  and  con¬ 
sistent,  numerous  issues  exist  in  practice. 
What  are  these  issues  and  how  have  they 
affected  the  ability  of  the  Air  Force  to 
comply  with  the  intent  of  the  Packard 
Commission?  The  next  sections  attempt 
to  answer  these  questions. 


laws,  regulations, 
and  directives  have 
defined  the  general 
structure,  roles,  and 
responsibilities  of 
the  Air  Force 
acquisition  chain 
from  flie  DAE  down 
to  the  program 
manager." 
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Issues 

In  spite  of  the  many  benefits  that 
acquisition  streamlining  and  reform  ini¬ 
tiatives  have  brought  to  the  Air  Force 
acquisition  community,  they  also  have 
introduced  some  issues  related  to  roles  and 
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Table  1.  Comparison  of  Responsibilities 


Responsibility 

DAC 

PEO 

MAD 

BPPBS  interface 

X 

Air  staff  interface 

X 

Congressional  interface 

X 

Mission  area  planning  and  integration 

X 

Requirements  coordination 

Shared 

(DAC  programs) 

Shared 

(PEO  programs) 

Shared 

Program  management  directive 

Shared 

(DAC  programs) 
(coordinates) 

Shared 

(PEO  programs) 
(coordinates) 

Shared 

(issues) 

Baselines 

Shared 

(DAC  programs) 

Shared 

(PEO  programs) 

Shared 

Defense  acquisition  executive 
summary  (DAES) 

Shared 

(DAC  programs) 

Shared 

(PEO  programs) 

Shared 

OSD  interface 

Shared 

(DAC  programs) 

Shared 

(PEO  programs) 

Shared 

Preparation  for  milestone  reviews 

X 

X 

Program  planning 

X 

X 

Program  oversight 

X 

X 

Reprogramming  approval 
in  execution  year 

X 

X 

Program  execution 

X 

X 

SPO  resources  requirements  generation 

X 

(DAC  programs) 

X 

(PEO  programs) 

SPO  resources  support 
(personnel,  facilities,  etc.) 

X1 

Rating  of  PEO  program  office  personnel 

X 

(except  PM)2 

X 

(PM  only) 

1  As  the  product  center  or  air  logistics  center  commander. 

2  Information  is  current  as  of  May  7, 1998. _ ___ _ _ _ _ _ - _ 

responsibilities  within  the  PEO/DAC/ 
MAD  organizational  structure.  Many  of 
these  issues  arise  from  the  introduction  of 
the  PEO  into  the  community  and  his  role 
relative  to  the  program  manager,  AFAE, 
DAC,  and  MAD.  The  PEO’s  role  is  unclear 
because  it’s  relatively  new,  it  naturally 


overlaps  the  roles  of  others  in  an  already 
complex  operating  environment,  and  no 
formal  process  exists  to  resolve  legitimate 
differences  between  the  PEO  and  the 
others.  Other  issues  deal  with  the  “dual- 
hatted”  nature  of  many  key  players,  which 
leads  to  having  two  bosses  or  two  sets  of 
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assigned  responsibilities.  The  first  few 
issues  deal  with  defining  the  role  of  the 
PEO. 

PEO:  Super  Program  Manager 
or  Junior  AFAE? 

The  lack  of  clarity  of  the  PEO’s  role 
has  led  some  observers  to  ask  where  the 
PEO’s  primary  function  resides  in  the 
direct  reporting  chain.  Is  the  PEO  a  “super 
program  manager,”  wrapped  in  the  details 
of  managing  and  executing  the  programs 
in  his  portfolio?  Or  is  the  PEO  a  “junior 
AFAE,”  providing  wisdom  and  “top 
cover”  for  the  program  manager,  yet  lack¬ 
ing  the  authority  to  make  milestone  deci¬ 
sions?  As  one  PEO  (and  former  program 
manager)  interpreted  this  relationship: 
“The  PEO  is  the  former  only  when  the 
program  manager  asks  for  help  or  a  train 
wreck  is  impending.  It’s  like  UPT  [under¬ 
graduate  pilot  training]:  take  control  too 
soon  and  the  student  doesn’t  learn;  too 
late  and  he  doesn’t  survive.  The  proper 
position  is  closer  to  the  latter.  The  PEO 
bridges  the  gap  between  the  program 
,  manager  and  the  AFAE.  The  PEO  belongs 
in  the  Pentagon  so  that  he  doesn’t  screw 
with  a  program  too  much.”9 

So,  the  PEO  must  provide  acquisition 
expertise  when  the  program  manager 
needs  it.  The  PEO  must  understand  and 
work  the  politics  inside  the  Beltway  and 
within  the  Pentagon  and  advise  the  pro¬ 
gram  manager  on  the  sensitivities  and 
realities.  The  PEO’s  forward  presence 
enables  him  to  defend  the  program  while 
screening  the  program  manager  from 
many  of  the  “brush  fires”  and  time- 
consuming  diversions  of  the  Washington 
environment. 

The  PEO  also  must  be  aware  of  the 
programmatics  and  challenges  of  the 


"In  reality,  then,  the 
PEO  is  bath  a  super 
program  manager 
and  a  junior  AFAE*" 


programs  in  his  portfolio,  and  ask:  What 
does  the  program  manager  need?  The  PEO 
is  in  a  unique  position  to  aid  his  program 
managers.  As  a  PEO  summed  up  the  situ¬ 
ation,  “The  PEO  appears  to  be  the  only 
person  with  a 
small  enough 
span  of  control 
to  help  the  pro¬ 
gram  manager. 

The  PEO  can 
get  on  the  phone 

with  enough  horsepower  and  contacts  to 
get  work  done.  The  center  commanders 
are  swamped  running  their  centers  and  the 
MADs  don’t  know  all  of  the  details.” 

In  reality,  then,  the  PEO  is  both  a  super 
program  manager  and  a  junior  AFAE.  He 
aids  each  end  of  the  Air  Force  acquisition 
chain  of  command  to  ensure  information, 
policy  and  guidance,  and  decisions  flow 
freely  and  accurately  in  both  directions. 


Dilution  of  the  PEO's  Role 

The  PEO  charter  specified  that  the 
“PEO  organization  is  a  field  agency 
reporting  directly  to  the  AFAE  and  not  part 
of  the  Assistant  Secretary’s  acquisition 
staff’  (Welch,  1990).  According  to  one 
PEO,  however,  that  relationship  is  often 
lost  on  current  senior  officials. 


Mr.  Welch  [AFAE]  and  General 
Jaquish  [his  principal  deputy]  had 
a  clear  view  in  the  beginning. 
They  did  not  have  the  PEOs 
attend  AQ  staff  meetings,  but 
rather  held  separate  meetings  with 
the  PEO  to  discuss  program 
execution.  PEOs  did  not  coordi¬ 
nate  on  or  sign  staff  summary 
sheets,  because  they  didn’t  do 
staff  work.  That  was  part  of  the 


31 


Acquisition  Review  Quarterly — Winter  1999 


reason  for  the  small  staff  size. 
Since  then,  there  has  been  a  blur¬ 
ring  of  roles;  much  of  the  PEO 
work  is  not  known  or  understood 
by  newcomers.  The  early  imple¬ 
mentation  dealt  with  what  should 
be  the  structure,  how  to  put  it 
together,  and  what  should  be  the 
charter  to  meet  the  Packard  Com¬ 
mission  intent.  With  the  turnover 
of  personnel,  the  new  folks 
haven’t  gone  back  to  review  the 
charter,  and  don’t  know  the 
responsibilities.  PEOs  now  have 
demands  that  compete  with  their 
primary  roles:  membership  on 
process  action  teams,  policy 
coordination,  etc. 


The  option  of  establishing  a  Deputy 
PEO  (0-6  or  GM-15)  position  can  help 
mitigate  the  increased  workload,  but  a 
problem  still  exists  in  the  basic  under¬ 
standing  of  the  PEO’s  position  and  func¬ 
tion.  Even  the  SAF/AQ  organizational 
chart  (Figure  2)  can  be  confusing.  Again, 
a  PEO  reminds  the  listener: 


PEOs  are  not  on  the  AQ  staff,  but 
rather  represent  field  operating 
agencies  and  carry  Air  Force  Pro¬ 
gram  Executive  Office  SEIs 
[special  experience  identifiers]. 
This  fact  is  lost  on  a  lot  of  people. 
The  MADs  come  in  from  Using 
commands  and  just  see  the  areas 
closely  aligned  with  their  respon¬ 
sibility;  they  don’t  see  the  activi¬ 
ties  unique  to  the  PEO:  contract¬ 
ing  approval  (business  clearance), 
acquisition  strategy  panels,  justi¬ 
fication  and  approvals,  acquisi¬ 
tion  plans,  source  selection 


authority,  undefinitized  contract 
actions,  and  [the  execution] 
budget. 

Clearly,  a  misunderstanding  of  the 
PEO’s  position  has  been  a  recurring  theme 
since  its  creation.  Much  of  the  confusion 
lies  in  the  overlapping  nature  of  the  roles 
and  responsibilities  of  the  PEO  and  those 
of  the  DAC  (as  the  center  commander)  and 
MAD. 

Overlapping  Responsibilities 
(PIO/DAC  (Center  Commander)) 

The  D  AC’s  role  as  a  center  commander 
establishes  a  closely  linked  relationship 
with  the  PEO  that  has  had  mixed  results 
on  execution.  The  product  or  air  logistics 
center  commander  is  responsible  for 
policies,  procedures,  facilities,  staff  sup¬ 
port,  personnel,  and  training.  These 
elements  are  essential  for  supporting  the 
PEO  program.  They  avoid  redundancy  and 
enable  a  small  PEO  staff.  However,  the 
operating  relationships  can  overlap  and 
become  unclear. 

The  central  issue  is  the  point  at  which 
support  ends  and  program  control  begins. 
Even  in  a  support  role,  the  center  com¬ 
mander  influences  program  execution  and 
effectiveness.  The  people  and  facilities  he 
or  she  provides,  the  policies  imposed,  and 
the  training  requirements  levied  all  influ¬ 
ence  the  quality  of  the  inputs  to  the  acqui¬ 
sition  process  and,  therefore,  affect  the 
product.  One  PEO  expressed  his  concern: 
“Separation  of  resource  control  and  pro¬ 
gram  execution  responsibility  is  unnatu¬ 
ral  in  our  culture,  and  we  do  not  have  a 
complete  understanding  of  the  interfaces.” 
This  issue  has  several  dimensions. 

First,  the  center  commander  provides 
the  people  that  serve  on  the  programs  in 
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accordance  with  his  charter.  However, 
PEOs  often  express  concern  that  their 
ability  to  influence  this  decision  has  been 
limited.  A  DAC  once  expressed  to  his 
staff:  “The  PEO  tells  me  what  positions 
he  needs  filled  on  one  of  his  programs, 
and  I  determine  who  will  fill  them.”  The 
center  commander,  in  essence,  determines 
the  relative  priority  of  this  program  when 
it  comes  to  providing  support.  Usually,  this 
concern  is  not  a  significant  problem.  How¬ 
ever,  one  PEO  related  that  he  had  lost  a 
senior  member  of  one  of  his  programs  (an 
0-6)  to  another  program  without  the  com¬ 
mander  notifying  him  of  the  reassignment. 

Second,  except  for  the  program  man¬ 
ager  (system  program  director,  or  SPD), 
the  center  commander  has  the  responsi¬ 
bility  for  evaluating  all  program  office 
personnel.  Thus,  functional  experts  who 
fill  matrix  positions  within  a  PEO  program 
face  the  potential  dilemma  of  divided 
loyalties. 

Third,  the  center  commander  controls 
the  budget  for  many  resources:  contrac¬ 
tor  support,  program  manager  salaries, 
travel  and  office  operations,  system- 
specific  software  engineering  and  new 
equipment  training.  Sometimes  the  PEO 
lacks  the  sufficient  visibility  and  control 
into  this  portion  of  the  budget  that  directly 
affects  the  program  baseline. 

Fourth,  in  reviewing  the  status  of 
functional  support  to  PEO  programs,  the 
center  commander  is  in  a  position  to 
influence  program  execution.  Certainly  a 
functional  review  is  appropriate,  but  prob¬ 
lems  arise  if  this  meeting  broadens  into  a 
program  review  where  direction  replaces 
advice  and  insight. 

Finally,  the  center  commander  is  in  a 
position  to  task  program  personnel  in  a 
manner  that  detracts  from  their  contribution 


to  the  program.  As  one  PEO  pointed  out, 
“When  the  center’s  contracting  officer 
reviews  a  document  for  my  program,  he’s 
working  for  me,  not  the  center  com¬ 
mander.  It’s  okay  to  pass  the  information 
on  to  the  commander,  but  not  okay  to 
impose  extra  work  on  the  program  [e.g., 
to  provide  the  data  in  the  center’s  preferred 
format].”  He  went  on  to  cite  other  con¬ 
flicts  with  his  program’s  needs,  such  as 
the  commander 
having  the  pro-  § 
gram  manager 
attend  an  offsite 
with  him  on 
center  matters 
or  tasking  a  pro- 
gram  0-6  to 
run  an  air  show. 

According  to  a  former  deputy  program 
director  on  a  major  program,  “Roughly  30 
percent  of  the  time  I  spent  on  the  program 
involved  handling  the  support  from  the 
DAC.” 


"Even  in  d  support 
rele,  the  center 
commander  influ¬ 
ences  program 
execution  and 
effectiveness* " 


These  factors  in  the  overlapping  rela¬ 
tionship  between  the  PEO  and  the  DAC 
can  confuse  the  program  manager  and  his 
SPO  personnel.  To  whom  do  they  go  to 
first  on  matters  of  advice  and  counsel? 
Sometimes  the  answer  is  as  much  a  mat¬ 
ter  of  proximity  (collocation  with  the 
center’s  functional  support)  and  rank 
(“How  do  you  say  ‘no’  to  a  three-star?”) 
as  it  is  the  acquisition  chain  of  command. 
In  fact,  said  a  PEO,  “Program  personnel 
have  occasionally  played  the  center  com¬ 
mander  and  PEO  off  each  other — depend¬ 
ing  on  which  position  or  chain  of  com¬ 
mand  better  serves  their  purpose.” 

These  potential  problem  areas  stem 
from  the  chartered  relationship  in  the  PEO/ 
DAC/MAD  acquisition  structure.  Fortu¬ 
nately,  they  usually  are  neither  frequent 
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nor  serious  in  nature.  The  PEO  and  the 
DAC  (center  commander)  both  have  re¬ 
sponsibilities  and  faithfully  seek  to  accom¬ 
plish  them  all.  Where  ever  they  conflict, 
negotiating  a  mutually  acceptable  solution 
is  the  best  course.  A  PEO  reinforced  this 
consideration,  “Having  a  good  rapport 
with  my  counterparts  prevents  adverse 
effects;  the  relationship  makes  it  work.” 


Overlapping  Responsibilities 


(PEO/MAD) 

The  PEO  and  MAD  also  experience  a 


complex  relationship  that  proves  both  ben¬ 
eficial  and  difficult.  Although  they  have 
different  job  descriptions,  their  areas  of 
responsibility  dovetail  at  best  and  conflict 
at  worst.  The  PEO  focuses  “downward” 
toward  the  SPOs,  contractors,  and  indus¬ 
try,  and  the  warfighters  related  to  the 

programs  in  his 


"The  magnitude  ot 
effort  to  usher  a 
weapon  system 
through  the  BPPBS 
and  acquisition 
milestone  processes 
is  far  beyond  what 
one  individual  and 


portfolio.  The 
MAD  perspec¬ 
tive  takes  an 
external  view, 
dealing  with  the 
Air  Staff  and 
Secretariat,  the 
other  Services, 


his  staff  can  OSD,  Congress, 

accomplish/'  the  media,  and 

the  warfighters 
related  to  his  mission  area.  The  PEO  deals 
with  the  execution  of  his  programs  with 
current  year  funds.  The  MAD  plans,  pro¬ 
grams,  and  budgets  for  future  year  efforts. 

These  different  perspectives  can  be  ben¬ 
eficial.  Different  views  and  goals  provide 
a  creative  tension.  The  magnitude  of  effort 
to  usher  a  weapon  system  through  the 
BPPBS  and  acquisition  milestone  pro¬ 
cesses  is  far  beyond  what  one  individual 
and  his  staff  can  accomplish.  However, 


acting  as  a  team,  the  PEO  and  MAD  can 
complement  each  other’s  role  to  jointly 
succeed  in  their  tasks.  For  example,  the 
MAD’s  interaction  with  Congress,  the  rest 
of  DoD,  and  other  outside  agents  clear  the 
PEOs  to  concentrate  on  program  execu¬ 
tion.  In  return,  the  PEO’s  detailed  program 
insight  can  facilitate  the  MAD’s  dissemi¬ 
nating  information,  coordinating  require¬ 
ments,  and  generating  BPPBS  inputs  and 
reclamas. 

Still,  the  overlap  in  the  activities  of 
these  two  offices  can  place  a  strain  on  the 
acquisition  process.  Sometimes  the  strain 
is  structural  in  nature.  The  PEO  has 
responsibility  for  current  year  execution, 
but  the  MAD  takes  the  lead  for  out-year 
budgets.  Clearly,  funding  cuts  to  the  latter 
affects  the  conduct  of  the  former.  Hence, 
the  PEO  is  accountable  for  sound  program 
execution,  but  has  little  control  over  the 
process  of  resourcing  future  needs.  At 
other  times,  the  strain  is  a  matter  of  expe¬ 
rience  and  perspective.  Take,  for  example, 
the  experience  of  a  former  Acting  SPD 
(program  manager)  of  a  major  joint  pro¬ 
gram.  “A  Congressional  staffer  sought  to 
reduce  our  program  office  manning  by 
50  percent.  Our  PEO  assembled  a 
rebuttal  to  fight  it,  but  the  MAD  didn’t 
think  it  mattered  and  failed  to  forward 
it  to  the  staffer.  It  took  significant  effort 
to  recover  most  of  this  cut.” 

The  program  manager,  too,  feels  this 
strain  in  needing  to  work  with  both  the 
PEO  and  the  MAD  on  issues  where  the 
lead  responsibility  is  unclear.  For  example, 
when  Congress  asks  questions  on  program 
details  (e.g.,  “What  are  you  doing  with  the 
management  reserve?”  “Why  aren’t  you 
on  contract?”),  should  the  MAD  answer 
the  question  because  he  is  the  Congres¬ 
sional  interface?  Or  should  the  PEO 
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answer  it  because  he  has  extensive  insight 
into  the  program?  Other  examples  of  this 
gray  area  are  “what-if”  drills  from  OSD, 
other  agency  inquiries,  foreign  military 
sales,10  and  taskings  from  outside  the 
directed  programs.11 

PEO  and  MAD  activities  will  continue 
to  overlap.  Said  one  PEO,  “It’s  possible 
to  do  some  of  each  other’s  stuff  (I 
wordsmith  all  answers  to  Congress),  but 
each  should  always  invite  the  other  to 
review  and  coordinate.  Interpersonal 
relations  determines  how  it  will  work 
out.” 

Recently,  SAF/AQ  (AFAE)  restruc¬ 
tured  the  MAD  and  PEO  portfolios  to 
better  align  and  ease  coordination  and 
communication.  Yet  perfect  one-on-one 
alignment  is  unlikely  between  program 
portfolios  and  mission  areas.  Added  one 
PEO,  “The  emergence  of  information 
systems  nearly  guarantees  more  than  one 
MAD  with  which  to  interface.  For 
example,  weapon  systems  using  informa¬ 
tion  systems  in  development  will  require 
the  overseeing  PEO  to  deal  with  the  MAD 
for  information  dominance  as  well  as  the 
director  overseeing  the  mission  area 
containing  the  weapon  system.” 

In  reality,  one  cannot  do  his  job  with¬ 
out  the  other.  Coordination,  teamwork, 
trust,  and  mutual  support  are  essential  to 
accomplishing  their  collective  tasks. 
These  attributes  compensate  for  the  lack 
of  clarity  between  in  the  role  of  the  PEO 
and  those  of  the  other  members  of  the 
acquisition  community.  However,  not  all 
of  the  issues  stem  from  the  establishment 
of  the  PEO.  Some  issues  result  from  the 
“dual-hatted”  nature  of  the  several  key 
players  within  the  community. 


"Dual-Hatting"  of 
Acquisition  Leadership 


The  “dual-hatting”  of  the  program  man¬ 
ager,  DAC,  and  AFAE  often  imposes 
difficulty  in  the  acquisition  process.  These 
individuals  have  to  respond  to  multiple 
“bosses”  or  have  to  perform  more  than  one 
set  of  responsibilities.  As  shown  earlier, 
the  program  manager  has  to  deal  effec¬ 
tively  with  the  PEO/D AC  and  PEO/M  AD 
overlaps.  In  the  first  case,  the  program 
manager  of  a  major  program  must  work 
with  the  DAC  (as  a  center  commander) 
for  his  resources  and  acquisition  support 
and  with  the  PEO  for  execution  matters. 

In  responding  to  Congressional  inquiries 
and  OSD  taskings,  he  must  deal  with  both 
the  MAD  and  the  PEO.  Again,  this  dual¬ 
ity  can  generate  confusion  and  redundant 
taskings. 

The  DAC,  too,  performs  dual  roles  and 
serves  more  than  one  boss.  In  fulfilling 
his  DAC  roles,  he  responds  to  the  AFAE 
on  all  acquisition  matters  concerning 
his  portfolio.  On  resources  and  acquisi¬ 
tion  support  and  • 

for  sustainment  „The  „d(|al.hatting,, 
matters  he  re-  of  ,he  program 
sponds  through  manager,  DAC,  and 
the  Air  Force  AFAE  often  imposes 
Materiel  Com-  difficulty  in  the 
mand  (AFMC)  acquisition  process. " 


commander  to 
the  Air  Force 

Chief  of  Staff.  Two  concerns  arise  from 
this  situation.  First,  like  the  program  man¬ 
ager,  the  DAC  has  a  complex  task  in 
satisfying  two  different  superiors  whose 
diverse  interests  potentially  overlap  and 
may  conflict.  Second,  the  1989  shift  in 
the  acquisition  chain  of  command  away 
from  the  AFSC  (now  integral  to  AFMC) 
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commander  to  the  AFAE  effectively  splits 
acquisition  from  sustainment.  One  of  the 
purposes  in  combining  AFSC  and  AFLC 
into  AFMC  was  to  instill  a  “cradle-to- 
grave”  perspective  in  integrated  weapon 
system  management.  While  the  execution- 
level  organization  may  embrace  this  per¬ 
spective,  it  is  not  a  natural  byproduct  of  at 
the  senior  Air  Force  command  structure. 

Finally,  the  AFAE  also  wears  two  hats 
and  serves  two  bosses.  For  example,  as 
S AF/AQ,  Mr.  Money  reported  to  SECAF 
Widnall  on  Air  Force  acquisition  matters. 


However,  as  the  AFAE,  Mr.  Money 
reported  to  the  DAE,  Dr.  Kaminski,  who 
was  the  MDA  for  Acquisition  Category 
(ACAT)  I  D  programs. 

These  dual-hatted  positions  are  not 
necessarily  counterproductive — they  may 

be  the  best  use 

of  acquisition 

"These  dual-hatted  rtise  and  a 


productive— -they 
may  be  the  best 
use  off  acquisition 
expertise  and  a 
logical  fusion  of 
roles  to  ensure  a 
consistent  policy, 
program  execution, 
and  reporting." 


roles  to  ensure 
a  consistent 
policy,  program 
execution,  and 
reporting.  Nev¬ 
ertheless,  coor¬ 
dination  and  in¬ 
teraction  with 
these  dual-hat¬ 


ted  positions 
can  be  complex  and  require  special  atten¬ 
tion  to  the  relationships. 

Thus,  the  Air  Force  acquisition  struc¬ 
ture  has  problems  in  role  definition, 
responsibility  overlap,  and  dual-hatted 
leaders.  How  do  these  issues  affect  the 
benefits  sought  from  implementing  the 
Packard  Commission  recommendations? 


Meeting  the  Packard 
Commission  Intent _ __ 

The  Packard  Commission  cited  the  lack 
of  accountability  and  unambiguous 
authority  in  acquisition  programs  and  the 
burdening  of  the  program  manager  with 
non-value-added  reporting  requirements. 
The  Air  Force  implementation  of  the  rec¬ 
ommended  three-tiered  (AFAE-PEO-PM) 
structure  for  major  defense  programs 
meets  the  Commission’s  intent  and  largely 
corrects  the  identified  shortcomings.  How¬ 
ever,  as  the  previous  section  points  out, 
this  structure  falls  short  of  total  compli¬ 
ance.  Consider  this  assessment  in  terms 
of  the  desired  characteristics  of  success¬ 
ful  projects:  clear  command  channels,  pro¬ 
gram  stability,  limited  reporting  require¬ 
ments,  small,  high-quality  staffs,  commu¬ 
nication  with  users,  and  better  system 
development.12 

Clear  Command  Channels 

The  evolution  of  the  Air  Force  acquisi¬ 
tion  structure,  a  direct  result  of  implement¬ 
ing  the  Packard  Commission  recommen¬ 
dations,  specifically  addresses  the  desire 
for  clear  command  channels.  DoD  policy 
instituted  the  AFAE-PEO-PM  and  AFAE- 
DAC-PM  direct  reporting  chains  for  all 
acquisition  programs,  establishing 
accountability  and  reducing  bureaucracy. 
The  AFAE  position  as  the  single  civilian 
responsible  for  all  Air  Force  acquisition 
matters  strongly  benefits  this  goal.  Pro¬ 
gram  managers  have  a  defined  and  direct 
reporting  path  through  at  most  one  indi¬ 
vidual  (a  PEO  or  D  AC)  to  the  AFAE.  Fur¬ 
ther,  PEOs  and  DACs  have  “privileged 
lines  of  communication  to  the  AFAE” 
(Welch,  1990).  This  streamlined  reporting 
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structure  can  be  particularly  useful  for 
situations  dictating  timely  acquisition 
communication  and  decision  making. 
According  to  one  PEO,  “Streamlining  has 
occurred.  Now  when  a  breach  occurs,  the 
reporting  and  working  of  the  issue  is  much 
faster.  [The  chain  is  no  longer]  ‘PM-center 
commander- AFMC/Commander-Chief  of 
Staff  of  the  Air  Force  (CSAF)-SECAF,’ 
but  rather  ‘PM-PEO-AFAE.’” 

While  program  execution  benefits  from 
this  three-tiered  reporting  structure,  the 
command  channel  is  less  clear  in  mat¬ 
ters  of  support  and  planning.  Previous 
discussions  illustrated  how  overlapping 
roles  and  responsibilities  and  the  dual- 
hatting  of  key  positions  introduce  com¬ 
plex  interactions  that  confuse  both  par¬ 
ticipants  and  observers  alike.  SPO  per¬ 
sonnel  must  keep  both  the  PEO  and  the 
center  commander  (DAC)  satisfied.  Also, 
they  must  respond  to  both  PEO  and  MAD 
taskings,  balancing  and  integrating  the 
information  to  meet  overlapping  needs. 
Further,  the  DAC  and  the  AFAE  have 
other  demanding  duties  they  perform  to 
satisfy  superiors  outside  the  direct 
reporting  chain  for  acquisition  matters. 
Again,  cooperation  and  coordination 
compensate  for  these  structural  imper¬ 
fections.  However,  compensation  is  less 
likely  for  those  individuals  who  interact 
with  the  acquisition  community  from  the 
outside. 

MAJCOM  commanders,  for  example, 
often  fail  to  appreciate  the  various 
nuances.  As  one  PEO  pointed  out,  “The 
four-stars  don’t  like  the  system.  It’s  due 
to  denial,  ignorance,  and  the  desire  to  talk 
to  another  four-star  vice  a  one-star.  They 
take  up  their  issues  with  the  AFMC 
commander  and  the  product  center  com¬ 
mander,  who  have  no  authority  on  the 


[PEO]  programs.  Instead,  they  need  to  talk 
to  the  AFAE  and  the  PEO.”  Even  then, 
confusion  may  persist:  On  one  occasion 
where  the  MAJCOM  commander  for¬ 
warded  an  issue  to  a  PEO,  it  involved  a 
weapon  system  already  transferred  out 
of  the  acquisition  realm  and  into  the 
CSAF-AFMC-system  support  manager 
sustainment  chain. 

Thus,  the  acquisition  chain  offers  a 
streamlined  command  chain  with  clear 
accountability  in  execution.  However, 
structural  conflicts  and  overlaps  in  respon¬ 
sibilities  complicate  the  handling  of 
several  important  matters  germane  to  the 
execution  process  and  the  principles  of 
integrated  weapon  system  management. 


Program  Stability 

The  impact  of  this  acquisition  structure 
on  program  stability  is  similar  to  its  affect 
on  the  command  chain.  The  focusing  of 
acquisition  ac¬ 
tivities  around 
the  three-tiered 
acquisition 
structure  facili¬ 
tates  a  coherent 
policy  and  ac¬ 
quisition  strat¬ 
egy.  A  PEO, 
with  responsi¬ 
bilities  restricted  to  the  execution  of  his 
portfolio  of  related  programs,  aids  pro¬ 
gram  stability  by  bridging  tne  interests  and 
needs  of  the  program  manager  and  the 
AFAE.  His  attentive  oversight  extends  the 
AFAE’s  effectiveness.  His  focused  protec¬ 
tion  of  the  program  manager’s  program 
from  outside  influences  helps  shelter  the 
program  from  destabilizing  funding  cuts 
and  non-value-added  taskings.  His  ability 
to  move  money  around  within  his  portfolio 


"The  focusing  of 
acquisition  activities 
around  the  three- 
tiered  acquisition 
structure  facilitates 
a  coherent  policy 
and  acquisition 
strategy;" 
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further  adds  to  program  stability.  Barring 
a  dilution  of  his  role  with  additional  staff 
duties,  the  PEO  is  a  stabilizing  influence 
on  his  portfolio’s  programs. 

Again,  however,  overlapping  responsi¬ 
bilities  and  dual-hatting  can  have  detri¬ 
mental  effects  on  program  stability.  For 
example,  while  the  PEO  can  control  cur¬ 
rent  year  execution  and  responses  to  fund¬ 
ing  cuts,  the  MAD  has  the  future  year  pro¬ 
gramming  and  budgeting  responsibilities. 
A  concerted  effort  of  both  the  MAD  and 
the  PEO  is  necessary  to  ensure  program 
stability. 

Limited  Reporting  Requirements 

Establishing  a  three-tiered  acquisition 
structure  directly  reduces  the  number  of 
levels  required  to  gain  approval  for  pro¬ 
gram  milestones.  Certainly  the  PEO’s  role 
and  location  in  the  Pentagon  relieve  the 
program  manager  from  encumbering 
briefing  demands.  Also,  by  handling  a 
portfolio  of  related  programs,  the  PEO  and 
the  DAC  filter  the  detail  and  quantity  of 
briefings  and  reports  the  AFAE  has  to 
receive. 

But  while  the  approval  briefing  require¬ 
ments  are  fewer,  the  program  manager  has 
increased  demands  of  coordination  and 
information  reporting  to  address  his  inter¬ 
face  with  the  center  commander  and  the 
MAD. 

Small  High-Quality  Staffs 

The  Air  Force  implementation  of  the 
PEO  position  limited  the  staff  size  to  six 
people.  Initial  arguments  suggested  that  a 
staff  more  than  three  times  that  large 
would  be  necessary  to  properly  oversee 
an  entire  portfolio  of  programs.  However, 
the  prevailing  attitude  of  senior  acquisi¬ 
tion  officials  was  that  the  2000  personnel 


located  in  the  SPOs  represented  the 
expertise  necessary  to  execute  the  pro¬ 
grams.  The  PEO  and  his  staff  needed  to 
tap  that  existing  capability  rather  than  add¬ 
ing  redundancy  to  it.  Still,  over  time  some 
PEO  staffs  did  expand  to  include  the 
position  of  a  deputy  PEO.  This  individual 
helps  shoulder  the  PEO’s  demanding  port¬ 
folio  (often  spread  across  three  product 
centers)  and  Pentagon  responsibilities. 

Communication  with  Users 

All  members  of  the  acquisition  chain 
have  a  responsibility  to  communicate  with 
the  warfighters  as  part  of  their  collective 
charters.  At  the  intermediate  level,  the 
PEO  shares  this  responsibility  with  the 
appropriate  MAD(s).  Their  perspectives 
are  slightly  different,  but  taken  together 
and  properly  coordinated,  they  should  be 
able  to  address  the  user’s  needs.  Again, 
though,  some  users  have  been  unclear  with 
whom  (e.g.,  PEO  or  MAD,  AFAE  or 
AFMC/CC)  they  should  deal  on  certain 
issues. 

Better  System  Development 

The  new  acquisition  structure  does  not 
specifically  address  system  development 
improvements.  Many  other  acquisition 
reform  initiatives  focus  on  this  character¬ 
istic.  Still,  a  command  chain  that  operates 
with  a  coherent  policy  and  strategy  and 
uses  efficient  reporting  mechanisms  is 
better  equipped  to  develop  affordable  and 
effective  weapon  systems. 

In  general,  then,  the  Air  Force  acquisi¬ 
tion  structure  meets  the  intent  of  the 
Packard  Commission.  It  reduces  bureau¬ 
cracy  and  provides  a  streamlined  com¬ 
mand  chain  accountable  for  program 
execution  and  reporting.  The  tiered  nature 
of  the  AFAE-PEO-PM  chain  allows  each 
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level  to  focus  on  key  needs  and  capabili¬ 
ties  that  enhance  program  stability  and 
enable  better  system  development.  The 
MADs  and  center  commanders  (DACs) 
play  vital  roles  in  this  complex  process. 
However,  their  support  also  complicates 
the  lines  of  authority,  control,  and  respon- 
sibilities.  Much  of  the  difficulty  is 
unavoidable  and  usually  does  not  create 
substantial  problems.  Still,  senior  leader¬ 
ship  continues  to  seek  solutions  to  refine 
the  overall  process.  What  are  some  of  the 
current  options  under  consideration? 


Options  for  Improvement 


As  the  PEO/DAC/MAD  acquisition 
structure  evolves,  the  participants  have 
proposed  numerous  alternative  implemen¬ 
tation  approaches  to  improve  both  process 
and  product.  One  improvement  recently 
incorporated  by  some  PEOs  was  the 
addition  of  the  deputy  PEO  position  to 
assist  in  the  oversight  role,  both  in  Wash¬ 
ington  and  in  the  field.  Another  involved 
the  restructuring  of  portfolios  to  better 
align  the  PEO  and  MAD  areas  of  respon¬ 
sibility.  Many  suggestions  have  fallen  by 
the  wayside,  victims  of  an  impracticable, 
unwanted,  or  unbalanced  implementation 
plan. 

However,  two  recent  ideas  proposed  at 
the  SAF/AQ  Workshop  in  June  1995 
warrant  discussion.  The  first  involves 
drawing  the  PEO  and  MAD  activities  into 
a  tighter  relationship  to  improve  coordina¬ 
tion  and  cooperation.  The  second  involves 
dividing  the  DAC  and  center  commander 
duties  among  two  senior  officials.  These 
proposed  changes  directly  address  two 
important  weak  points  in  the  Air  Force 
acquisition  structure:  the  overlap  in 


responsibilities  between  the  PEO  and  the 
MAD,  and  the  dual-hatted  role  of  the 
DAC. 


"Collocation  helps  to 
build  trust  and 
cooperation*  This 
arrangement 
improves  efficiency 
through  shared 
expertise  and 
improved 
coordination*" 


Collocate  or  Combine 
MAD  and  PEO  Staffs 

One  approach  to  reducing  the  difficul¬ 
ties  experienced  due  to  the  PEO/MAD 
overlap  in  responsibilities  is  to  collocate 
or  combine  their  staffs.  Collocation  helps 
to  build  trust  and  cooperation.  This 
arrangement  improves  efficiency  through 
shared  expertise 
and  improved 
coordination.  It 
also  facilitates  a 
common,  bal¬ 
anced  focus  on 
BPPBS  inputs, 
program  execu¬ 
tion,  and  inter¬ 
action  with  all  | . . 

interfaces,  with-  .  . 
in  and  outside  the  acquisition  community. 
SAF/AQ  recently  intended  to  collocate  the 
PEO  and  MAD  staffs,  but  a  scheduled 
move  out  of  the  Pentagon  (during  its 
refurbishment)  interrupted  the  plan.  Com¬ 
bining  staffs  extends  the  collocation  con¬ 
cept  further  and  also  permits  a  reduction 
in  manning. 

Unfortunately,  these  initiatives  have 
drawbacks  as  well.  The  current  structure 
provides  a  “creative  tension”  that  two 
different  perspectives  bring.  Areas  of 
concern  to  both  parties  undergo  a  system 
of  checks  and  balances.  One  PEO 
expressed  a  concern  of  the  PEO  role 
becoming  subordinate  to  that  of  the  MAD. 
Combining  the  staffs  would  make  dual 
leadership  cumbersome  and  potentially 
counterproductive.  Another  difficulty  lies 
in  the  proper  handling  of  all  matters  the 
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PEO  and  MAD  currently  address;  com¬ 
bining  these  activities  creates  an  unwieldy 
span  of  control.  Finally,  because  the  PEO 
portfolios  and  the  MAD  areas  of  respon¬ 
sibility  do  not  perfectly  align,  some 
discontinuities  would  remain  across  the 
acquisition  front  between  the  two  sets  of 
responsibilities. 

Still,  the  collocation  or  near  collocation 
of  staffs  has  merit.  The  benefits  of 
improved  efficiency  and  interaction  be¬ 
tween  the  PEO  and  the  MAD  reduce  the 
problems  generated  by  their  overlap  in 
responsibilities.  Careful  attention  to  the 
drawbacks  can  mitigate  their  impact. 

Product  Center  Realignment- 
Deputy  Commander  as  "Field  PEO" 

Another  proposal  from  the  SAF/AQ 
Workshop  entailed  separating  the  DAC 
and  center  commander  duties.  Center 
commanders  would  continue  handling 
personnel,  processes,  training,  and  sup¬ 
port.  The  deputy  commander  would 
assume  the  DAC  duties  and  become  es¬ 
sentially  a  “Field  PEO.”  His  responsibili¬ 
ties  would  be  the  same  as  the  current 
PEOs,  except  he  would  operate  at  the 
product  center  and  oversee  a  portfolio  of 
“other  than  major  or  selected”  programs. 

Because  of  the 
acquisition  cat- 
"Careful  attention  eg0ry  of  the  pro- 

to  the  drawbacks  grams  involved, 

[of  staff  collocation]  p0sdng  this  in- 

can  mitigate  their  dividual  at  the 

lm|>aCt#  Pentagon  would 

not  be  neces¬ 
sary.  This  restructuring  would  eliminate 
the  dual-hatted  problem  of  running  a 
product  center  and  serving  as  the  DAC. 

While  this  proposal  reduces  the  span 
of  control  of  a  critical  acquisition  and 


leadership  position,  it  still  does  not  address 
the  PEO/center  commander  overlap  in 
responsibilities  in  resourcing  and  execut¬ 
ing  a  program.  Instead,  it  adds  a  second 
overlap  between  the  field  PEO  (DAC)  and 
the  center  commander.  Two  individuals 
would  need  to  address  issues  formerly 
resolved  by  a  single  individual — and  one 
of  these  individuals  would  be  directly 
reporting  to  the  other. 

The  field  PEO  concept  makes  sense. 
However,  to  properly  realize  its  benefits, 
the  field  PEO  should  report  to  the  AFAE 
and  not  the  center  commander.  This 
implementation  would  not  solve  the  over¬ 
lap  issue,  but  it  better  serves  program 
execution  and  accountability. 


Conclusions  and  Recommendations 

The  close  scrutiny  given  to  the  acqui¬ 
sition  process  over  the  past  decade  identi¬ 
fied  a  need  for  streamlining  and  reform. 
One  initiative  created  the  PEO  and  “in¬ 
serted”  this  position  into  a  three-tiered 
direct  reporting  chain.  The  PEO’s  duties 
focus  on  overseeing  the  execution  of  a 
portfolio  of  related  programs.  He  provides 
the  program  manager  top  cover,  helps  the 
AFAE  with  his  span  of  control,  and 
bridges  the  linkage  between  the  two. 

Inserting  the  PEO  position  modified  an 
existing  structure.  The  implementation  did 
not  result  from  a  bottoms-up  construction. 
Consequently,  incongruities  developed. 
The  roles  and  responsibilities  of  the  PEO 
overlapped  those  of  the  DACs/center 
commanders  and  the  MADs.  Blurred 
roles,  conflicting  responsibilities,  and 
dual-hatted  leadership  have  occasionally 
undermined  the  program  execution  and 
support  process.  Often,  the  program 


40 


The  USAF  PEO/DAC/MAD  Structure 


manager  and  the  SPO  find  themselves 
caught  between  two  worthwhile  but 
conflicting  demands. 

Yet  the  process  can  and  has  worked. 
Personality,  trust,  coordination,  and  coop¬ 
eration  can  foster  the  relationships  and 
efficiency  to  overcome  these  hurdles.  The 
fact  that  many  of  the  key  players  in  the 
PEO/D  AC/M  AD/PM  structure  have  filled 
more  than  one  of  these  positions  promotes 
a  bond  of  understanding.  Unfortunately, 
the  turnover  of  key  participants  requires 
continuous  adjustment  and  re-education 
along  the  learning  curve  to  make  the 
system  work. 

The  process  continues  to  evolve.  Room 
for  improvement  still  exists.  The  genesis 
of  this  improvement  lies  in  continued 
discussions  (e.g.,  offsites)  that  bring  issues 
to  forefront  where  they  can  be  aired  and 
resolved.  These  discussions  generate 
options.  Some  options,  though  plausible, 
fall  short  for  a  variety  of  reasons  (e.g., 
current  structure,  inertia,  different 
perspectives,  different  functional  respon¬ 
sibilities,  and  impractical  span  of  control). 

Other  options,  though,  stand  out  as 
reasonable  improvements  worthy  of 
implementation.  In  particular,  I  recom¬ 
mend  that  senior  Air  Force  leadership  give 
further  consideration  to  the  following  two 
modifications  to  currently  proposed 
changes. 


First,  at  the  earliest  opportunity,  collo¬ 
cate  (or  nearly  collocate)  the  PEO  and 
MAD  staffs  to  increase  the  positive 
aspects  of  close  interaction  and  to  resolve 
issues  due  to  overlaps  in  responsibility.  Do 
not  combine  these  staffs,  but  rather  retain 
their  independence.  Their  spans  of  con¬ 
trol  are  manageable  and  their  different 
perspectives  promote  a  creative  tension 
that  can  ensure  an  optimized  and  balanced 
solution. 

Second,  create  a  field  PEO  position  that 
assumes  the  current  DAC  responsibilities. 
This  individual  would  report  directly  to 
the  AFAE  for  his  portfolio  of  programs. 
Like  the  current  PEOs,  field  PEOs  would 
have  a  small  staff  and  receive  acquisition 
support  from  the  center  commander.  The 
PEO/center  commander  overlap  in 
responsibilities  would  remain  an  area  of 
concern  requiring  cooperation  and  further 
attention. 

These  recommendations  seek  to 
enhance  an  acquisition  structure  that 
currently  handles  the  difficult  and  com¬ 
plex  acquisition  process  in  spite  of  its 
structural  flaws.  Further  clarification  of 
roles  and  responsibilities  is  appropriate. 
The  interfaces  and  overlaps  between  po¬ 
sitions  should  yield  synergy,  not  duplic¬ 
ity  or  conflict.  Continued  refinement  to  the 
Air  Force  acquisition  structure  will  ensure 
a  successful  pattern  for  future  weapon 
systems  acquisition. 


Lt  Col  Charles  W.  Pinney  is  the  deputy  program  director  for  the  Airborne  Laser. 
He’s  a  graduate  of  the  U.S.  Air  Force  Test  Pilot  School  and  holds  master’s 
degrees  in  aeronautics,  electrical  engineering,  business  administration,  and 
national  resources  strategy.  He  is  a  graduate  of  the  Defense  Systems  Manage¬ 
ment  College  PMC  90-1  and  EPMC  98-3  courses  and  is  a  Defense  Acquisition 
Corps  member  certified  at  Level  111  in  program  management,  test  and  evalua¬ 
tion,  and  systems  planning,  research,  development,  and  engineering. 

(E-mail  address:  PinneyC@plk.af.mil) 
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Endnotes 


1.  Synonymous  terms  for  the  service 
acquisition  executive  (SAE)  are  the 
component  acquisition  executive 
(CAE)  and,  for  the  Air  Force,  the  Air 
Force  acquisition  executive  (AFAE). 

2.  Synonymous  terms  for  the  program 
manager  include,  in  some  cases  (i.e., 
for  major  programs),  program  direc¬ 
tor  (PD),  or  system  program  director 
(SPD).  The  term  single  manager, 
which  can  represent  a  SPD,  product 
group  manager,  or  materiel  group 
manager,  may  also  substitute  for  pro¬ 
gram  manager  in  certain  (usually 
acquisition)  cases. 

3 .  Originally  designated  as  USD( A),  this 
individual  also  serves  as  the  defense 
acquisition  executive  (DAE). 

4.  DoD  Instruction  5000.2.  Assignment 
of  Program  Executive  Responsibil¬ 
ity — Description:  “Each  component 
acquisition  executive  should  appoint 
a  number  of  program  executive  offic¬ 
ers  (PEOs)  who,  like  group  general 
managers  in  industry,  should  be 
responsible  for  a  reasonable  and 
defined  number  of  acquisition  pro¬ 
grams.  Program  managers  for  these 
programs  should  be  responsible 
directly  to  their  respective  PEO  and, 
on  program  matters,  report  only  to 
him.  In  other  words,  every  major  pro¬ 
gram  should  be  set  up  as  a  center  of 
excellence  and  managed  with  modem 
techniques.” 


5 .  AF  Policy  Directive  63- 1 : 

Para.  1 .4.3. 1 .  Air  Force  AC  AT  I D  pro¬ 
grams  are  managed  by  the  AFAE,  a 
program  executive  officer  (PEO),  and 
an  SPD,  with  the  defense  acquisition 
executive  as  the  MDA.  The  AFAE  is 
the  MDA  for  AC  AT  I C  programs.  Oc¬ 
casionally,  an  ACAT  I  program  may 
not  be  assigned  to  a  PEO,  and  the  SPD 
will  report  directly  to  the  AFAE.  Air 
Force  ACAT  I  C  programs  that  meet 
the  conditions  specified  in  Depart¬ 
ment  of  Defense  (DoD)  Instruction 
5000.2,  Defense  Acquisition  Manage¬ 
ment  Policies  and  Procedures,  Febru¬ 
ary  23,  1991,  may  be  transferred  to  a 
designated  acquisition  commander 
(DAC). 

Para.  I.4.3.2.  Major  Automated  Infor¬ 
mation  Systems  programs  (ACAT  I 
M)  are  managed  by  the  AFAE,  a  PEO, 
and  an  SPD  with  the  Assistant  Secre¬ 
tary  of  Defense  (Command,  Control, 
Communications,  and  Intelligence)  as 
the  MDA. 

Para.  1 .4.3.3.  Air  Force  ACAT  II  pro¬ 
grams  are  managed  by  the  AFAE,  the 
DAC,  and  an  SPD,  unless  the  program 
has  been  selected  by  the  AFAE  for 
special  oversight  and  assigned  to  a 
PEO.  The  AFAE  is  the  MDA  for 
ACAT  II  programs. 

Para.  1 .4.3.4.  Air  Force  ACAT  III  and 
IV  programs  are  managed  by  the 
AFAE,  the  DAC,  and  an  SPD,  unless 
the  program  has  been  selected  by  the 
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AFAE  for  special  oversight  and 
assigned  to  a  PEO.  The  AFAE  will 
exercise  his  or  her  responsibilities  on 
an  exception  basis  when  considered 
necessary  as  a  result  of  a  report  from 
the  DAC.  The  DAC  is  the  MDA  for 
ACAT  III  and  IV  programs.  DACs 
may  recommend  to  the  AFAE  that 
smaller  dollar  value,  low-risk  pro¬ 
grams  be  designated  as  ACAT  IV.  The 
MDA  for  these  ACAT  IV  programs 
may  then  be  delegated  below  the  DAC 
by  the  AFAE. 

6  AF  Policy  Directive  63-1,  para. 
1.6.1....  Unless  otherwise  directed  by 
SAF,  the  AFAE  is  the  MDAfor  ACAT 
I C  through  IV  programs  and  may  del¬ 
egate  this  authority  as  appropriate. 
With  the  exception  of  selected  pro¬ 
grams,  the  AFAE  has  delegated  MDA 
for  ACAT  III  and  IV  programs  to  the 
appropriate  DAC.  The  ASAF(A)  is 
the  AFAE,  the  senior  procurement 
executive,  and  the  senior  information 
resource  management  official. 

7.  Both  PEO  and  DAC  portfolio  contents 
are  available  on  the  Internet  at  the 
S  AF/AQ  Web  site,  www.safaq.af.mil. 


8.  Consistent  with  the  responsibilities 
outlined  in  the  Program  Manage¬ 
ment  Directive,  as  authorized  by  the 
applicable  MAD. 

9.  The  National  Defense  University 
academic  nonattribution  policy 
precludes  identifying  the  specific 
source  of  the  cited  material  unless  it 
has  been  released  previously.  Subse¬ 
quent  unattributed  quotes  in  this 
article  reflect  this  policy. 

10.  Foreign  military  sales  also  involve 
SAF/IA. 

1 1 .  Examples  include  PEO/MAD  overlap 
in  responding  to  imposed  environ¬ 
mental  mandates  and  data  collection 
requests  on  areas  such  as  composites 
development. 

12.  Remember,  however,  that  this  assess¬ 
ment  relates  only  to  the  impact  of  the 
new  acquisition  structure,  and  not  the 
contribution  of  other  acquisition 
reform  initiatives,  on  the  six  desired 
characteristics. 
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OPINION 


OPEN  SYSTEMS  AND 
THE  SYSTEMS 
ENGINEERING  PROCESS 

MUhael  Hanratty,  Robert  H.  Lightsey,  and  Arvid  0.  Larson 


The  point  of  open  systems  acquisitions  is  to  ensure  that  we  obtain  the  most 
effective  weapon  systems  possible— systems  that  are  affordable,  accommodate 
changing  technology,  and  promote  multiple  sources  of  supply.  Establishing  a 
disciplined  systems  engineering  approach  is  essential  to  achieving  this  goal. 


The  open  system  approach  is  both  a 
technical  approach  to  systems  en¬ 
gineering  and  a  preferred  business 
strategy  that  is  becoming  widely  applied 
by  commercial  manufacturers  of  large 
complex  systems.  It  has  the  attention  of 
Department  of  Defense  (DoD)  managers, 
who  have  mandated  its  use  by  DoD  sys¬ 
tems  developers.  Why?  Because  without 
such  a  change  in  system  development 
practice,  DoD  risks  being  unable  to  afford 
to  maintain  continued  superior  combat 
capability. 

Today,  legacy  weapons  systems  con¬ 
tinue  to  be  developed  with  their  own  often- 
unique  and  frequently  closed  infrastruc¬ 
tures,  making  upgrading  or  modifying 
them  over  their  expected  lifetimes  (20  to 
40  years)  both  problematic  and  expensive. 
Also,  reduced  procurement  budgets  and 
increased  dominance  of  commercial  tech¬ 
nology  cause  acquisition  managers  to  rely 


increasingly  on  commercial  markets  for 
affordable  product  development  and 
support.  So,  as  DoD’s  role  shifts  from 
being  a  technology  producer  to  being  a 
technology  consumer,  it  relies  more  on 
commercial  products  whose  design  is  not 
controlled  by  DoD  and  whose  lifetimes 
are  much  shorter  and  more  volatile  than 
the  weapons  systems  they  support  (e.g., 
years  vs.  decades).  As  a  result,  acquisition 
managers  risk  relying  on  unique  products 
provided  by  a  single  supplier  at  high  non¬ 
competitive  prices  and  with  little  oppor¬ 
tunity  for  technology  insertion  by  other 
suppliers. 

Here  we  discuss  the  need  for  a  rigor¬ 
ous  systems  engineering  process  that 
incorporates  open  systems  concepts  and 
principles — where  resulting  system 
designs  more  readily  accommodate 
changing  technology  to  achieve  cost, 
schedule,  and  performance  benefits  by 


47 


Acquisition  Review  Quarterly — Winter  1999 


promoting  multiple  sources  of  supply  and 
technology  insertion. 

The  Need  for  an  Open 
Systems  Design  Approach 


An  open  systems  design  approach  can 
allow  a  weapon  system  program  office  to 
achieve  and  maintain  combat  superiority 
in  today’s  challenging  acquisition  environ¬ 
ment.  This  approach  focuses  the  design 
process  on  lowering  the  entire  life-cycle 
costs  (LCCs)  of  weapon  systems — in  contrast 
to  current  practice,  in  which  a  dispropor¬ 
tionate  focus  is  placed  on  the  short-term 
goal  of  having  the  lowest  development 
costs.  Figure  1  illustrates  that  well  over 
half  of  total  LCCs  are  incurred  post-IOC 
(initial  operational  capability)  during  the 
service  lifetime  (Defense  Systems  Man¬ 
agement  College,  1990).  The  ability  of  the 
open  systems  design  approach  to  improve 
life-cycle  supportability  is  becoming  an 
even  more  important  issue  as  DoD  limits 
the  number  of  new  weapon  systems 
procurements  and  extends  the  life  of  the 
systems  currently  fielded. 

It  seems  clear  that  DoD  managers 
should  concentrate  on  doing  things  in  sys¬ 
tems  engineering  and  development  that 
will  decrease  costs  during  production  and 
especially  during  the  operations  and  sup¬ 
port  (O&S)  phase.  An  open  systems 
approach,  basing  the  weapon  system’s 
design  on  open,  commercially  supported 
interface  standards  with  the  prospects  of 
a  large  supplier  and  customer  base, 
focuses  the  systems  engineering  process 
on  developing  system  designs  that  con¬ 
sider  life-cycle  support  requirements  up 
front  and  that  support  system  evolution 
throughout  the  system’s  life. 


An  open  systems  approach  also  miti¬ 
gates  the  increased  risks  of  obsolescence 
due  to  shortened  technology  cycle  time. 
Obsolescence  risks  are  significant  because 
technology  cycle  time,  sometimes  on  the 
order  of  months,  far  outpaces  weapon  sys¬ 
tem  development  cycle  time,  typically  8 
to  1 5  years.  By  the  time  a  system  is  fielded, 
supporting  technologies  are  often  out¬ 
dated— the  U.S.  military  cannot  afford  to 
be  three  or  four  technological  generations 
behind  what  is  available  on  the  commer¬ 
cial  market.  Open  systems  designs,  using 
commercially  supported  interface  stan¬ 
dards  that  permit  upgrade  at  a  relatively 
low  cost,  specifically  address  issues  of 
affordability  and  supportability  associated 
with  long-lived  systems  by  facilitating 
evolutionary  upgrade  with  new  technol¬ 
ogy.  Generally,  this  results  in  superior 
combat  capability  over  the  total  system 
life  cycle,  usually  at  a  lower  cost  to  the 
government. 

Another  reason  that  open  systems  have 
become  so  attractive  is  that  DoD  is  no 
longer  the  dominant  force  in  the  market¬ 
place  and  DoD’s  procurement  budget  has 
been  drastically  reduced.  DoD  no  longer 
has  the  luxury  of  technology  dominance, 
funded  by  seemingly  unlimited  budgets. 
In  prior  decades,  DoD  requirements  drove 
development  of  new  products  and  new 
technology.  In  today’s  environment  the 
opposite  is  true;  commercial  demand 
drives  product  and  technology  develop¬ 
ment.  However,  DoD  can  now  take 
advantage  of  commercial  innovation, 
research,  and  development  to  drive  down 
its  cost  of  developing,  acquiring,  and 
maintaining  weapon  systems,  leveraging 
the  commercial  investment  to  make  the 
most  of  available  and  shrinking  defense 
funds.  An  open  systems  approach,  using 
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open  interfaces  supported  by  commercial 
and  nondevelopmental  components,  can 
substantially  facilitate  this  leveraging. 

The  bottom-line  issue  is  not  only  cost: 
the  lives  of  our  servicemen  may  depend 
on  shortened  technology  insertion  cycle 
times.  In  a  global  market,  everyone, 
including  our  potential  adversaries,  will 
gain  increasing  access  to  the  same  com¬ 
mercial  technology  base.  The  military 
advantage  goes  to  the  nation  that  has  the 
best  cycle  time  to  capture  the  very  best 
commercially  available  technologies, 
incorporate  them  in  weapon  systems,  and 
get  them  fielded  first.  Moreover,  since 
coalition  operations  with  our  allies  place 
a  high  premium  on  interoperability,  it 
is  essential  that  our  systems  be  compat¬ 
ible  and  capable  of  being  sustained 
through  a  common  logistics  support  struc¬ 
ture.  Open  systems  specifications  and 


standards  promote  standard  interfaces  and 
interoperability  with  our  friends  and  allies. 

Each  of  these  many  issues  will  continue 
to  substantively  challenge  past  DoD 
acquisition  practices  throughout  the  fore¬ 
seeable  future.  As  a  result,  DoD  finds  itself 
with  few  alternatives  but  to  drastically 
alter  the  way  it  develops,  produces,  and 
supports  its  weapon  systems.  It  is  neither 
economically  nor  technologically  feasible 
to  continue  traditional  closed  design 
approaches.  DoD  is  increasingly  com¬ 
pelled  to  move  toward  a  more  open 
weapon  systems  design  alternative. 

Open  Systems  Design  Concepts 

Simply  put,  the  concept  of  open  sys¬ 
tems  is  a  commonsense  approach  that  has 
substantial  promise  as  a  way  to  meet 
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DoD’s  continuing  need  to  support  systems 
over  increasingly  long  life  cycles  in  an 
environment  of  decreasing  resources.  At 
a  time  when  the  development  of  a  complex 
system  can  span  several  generations  of  the 
faster  moving  technologies,  open  system 
architectures  offer  the  tantalizing  prospect 
of  facilitating  performance  upgrades  at 

affordable  costs 


"Open  systems  are 
those  that  can  be 
supported  by  the 
marketplace,  rather 
than  being 
supported  by  a 
single  (or  limited) 
set  of  suppliers, 
due  to  the  unique 
aspects  of  the 
design  chosen." 


for  the  lifecycle 
of  the  system. 
The  potential 
and  practice  of 
open  systems 
design  as  an 
emerging  topic 
within  the  sys¬ 
tems  engineer¬ 
ing  discipline 
has  now  been 
with  us  for  sev¬ 


eral  years.  In  addition,  the  use  of  open  sys¬ 
tems  has  received  the  attention  and  sup¬ 
port  of  the  highest  levels  of  DoD.  In  1996, 
DoD  issued  a  revised  directive  DoD 
5000.2-R,  which  instructs  program  man¬ 


agers  to  employ  open  systems  as  a  design 
consideration  in  defense  systems  engi¬ 
neering  (DoD,  1998)  This  directive  was 
subsequently  revised  and  stengthened 
with  Change  3  in  March  1998.  The  sys¬ 
tems  engineering  process,  with  specific 
reference  to  the  consideration  of  open  sys¬ 
tems  designs,  is  integral  to  achieving  the 
benefits  of  open  systems  designs. 

While  there  are  many  definitions  of 
open  systems,  most  have  a  few  character¬ 
istics  in  common  (Department  of  the 
Navy,  1993).  Open  systems  are  those  that 
can  be  supported  by  the  marketplace, 
rather  than  being  supported  by  a  single 
(or  limited)  set  of  suppliers,  due  to  the 
unique  aspects  of  the  design  chosen.  Open 


systems  architectures  are  achieved  by 
having  the  design  focus  on  commonly 
used  and  widely  supported  interface  stan¬ 
dards.  One  might  think  in  terms  of  the 
axle-wheel-tire  interfaces  employed  on 
commercial  cars.  By  adhering  to  common 
standards  at  the  interfaces,  the  consumer 
is  able  to  buy  tires  from  a  multitude  of 
suppliers,  rather  than  being  forced  to  buy 
from  a  single  source,  as  might  be  the  case 
if  the  interface  characteristics  were  unique 
to  a  single  supplier.  This  ensures  costs  and 
quality  that  are  controlled  by  the  forces  of 
competition  in  the  marketplace.  Further¬ 
more,  the  continued  support  of  the  sys¬ 
tem  is  not  subject  to  the  risks  associated 
with  having  a  single  supplier  go  out  of 
business  or  cease  supporting  the  standard. 
As  the  technologies  associated  with  tires 
change  with  time,  the  customer  can  con¬ 
tinue  to  upgrade  and  support  his  vehicle 
with  tires  that  are  built  to  the  accepted 
industry  standard  (e.g.,  from  conventional 
sidewall  bias-ply  technology  tires  to  steel- 
belted  radial-ply  technology  tires). 

But  despite  all  the  high-level  attention 
on  open  systems,  DoD  program  manag¬ 
ers  must  exercise  some  care  and  judgment 
in  their  application  of  the  open  systems 
approach.  It  does  not  represent  a  new 
approach  that  replaces  and  makes  obso¬ 
lete  previous  approaches  to  engineering 
complex  systems.  Moreover,  managers 
should  not  simply  implement  an  open 
standard  without  careful  consideration  of 
where  (in  the  system  hierarchy)  it  makes 
sense  to  impose  standards,  nor  should 
they  simply  grasp  for  a  commercial  item 
(Cl)  solution,  whether  or  not  the  solu¬ 
tion  leads  to  the  benefits  of  open  systems 
architectures.  Such  actions  may  encour¬ 
age  program  managers  to  declare  that  they 
are  achieving  open  systems  attributes, 
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whether  or  not  the  system  design  is  well 
thought  out  to  take  full  advantage  of  the 
benefits  that  the  open  systems  approach 
offers.  This  may  give  the  appearance  of 
achieving  open  systems  architectures  but, 
in  fact,  such  short-sighted  decisions  work 
against  the  long-term  viability  of  the  sys¬ 
tem.  The  open  system  concept  does  not 
replace  the  need  for  following  a  rigorous 
systems  engineering  process  but,  in  fact, 
requires  more  rigor  to  ensure  that  open 
systems  benefits  are  achieved. 

Open  Systems  Applied  Within 
the  Systems  Engineering  Process 

Systems  engineering  is  fundamentally 
a  problem-solving  process  that  translates 
needs  and  requirements  as  inputs  into 
designs  and  products  as  outputs.  The  sys¬ 
tems  engineering  process  typically  starts 
with  problem  definition  as  requirements 
are  analyzed.  Alternative  solutions  or  sys¬ 
tem  architectures  are  developed,  usually 
initially  through  techniques  such  as  func¬ 
tional  analysis  and  data  flow  analysis. 
Alternative  physical  designs  are  then 
developed  to  satisfy  the  functional  or  data 
flows.  Trade  studies  and  risk  analyses  are 
applied  to  select  a  preferred  design  solu¬ 
tion,  and  that  solution  is  verified  against 
the  original  requirements. 

This  process,  properly  applied,  results 
in  a  flow-down  of  requirements  from  the 
system  level  to  the  items  below  system 
level.  As  these  requirements  flow  down, 
the  design  requirements  for  the  items 
below  system  level  are  defined.  Once 
these  lower  level  design  requirements 
are  made  final,  the  design  process  pro¬ 
ceeds  to  completion.  The  result  is  a 
design  that  associates  physical  entities 
with  the  functions  the  system  must  per¬ 
form,  and  is  consistent  with  the  levels  of 


performance  required  and  with  the 
interfaces  specified. 

This  process,  applied  without  con¬ 
straints,  will  lead  to  the  design  of  a  sys¬ 
tem  in  which  every  item  is  optimized  to 
the  requirements  in  terms  of  function,  per¬ 
formance,  and  interface.  Too  often,  the 
results  in  DoD  have  been  systems  that  are 
unique  in  their 

designs,  that  "Systems  engineer- 
perform  their  ing  is  fundamentally 
missions  quite  a  problem-solving 
well,  but  that  process  that  trans- 
require  unique  lates  needs  and 
equipment  and  requirements  as 
parts  to  support  inputs  into  designs 
them,  and  that  Produ*t*  « 

can  be  sup  owfPM,s" 
ported  only  by  a 

limited  set  of  suppliers.  This  has  histori¬ 
cally  been  a  prescription  for  closed  sys¬ 
tems  that  are  both  difficult  and  costly  to 
support. 

The  challenge  in  DoD  is  to  design  sys¬ 
tems  to  take  advantage  of  open  systems 
concepts  where  that  makes  sense,  while 
continuing  to  meet  the  needs  and  require¬ 
ments  of  operational  forces.  The  solution 
is  not  to  suddenly  abandon  good  systems 
engineering  and  simply  impose  standard 
interfaces  at  some  point  in  the  system. 
Neither  is  the  answer  likely  to  be  found  in 
indiscriminately  importing  Cl  solutions 
into  the  system  architecture.  Rather,  the 
solution  is  to  perform  good  systems  engi¬ 
neering  while,  as  DoD  dictates,  employ¬ 
ing  open  systems  as  a  design  consideration 
from  the  outset.  The  challenge,  then,  is  to 
integrate  systems  engineering  and  open 
systems  design. 

To  this  end,  the  use  of  architectures  in 
DoD  has  become  a  preferred  management 
approach  for  implementing  an  open 
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systems  approach  (Under  Secretary  of 
Defense,  1996).  DoD  has  implemented 
this  concept  by  defining  an  interrelated  set 
of  architectures:  operational,  system,  and 
technical  (Figure  2).  Basically,  the  opera¬ 
tional  architecture  specifies  the  user 
requirements,  which  are  used  as  inputs  to 
the  systems  engineering  process  to  even¬ 
tually  build  the  weapon  system.  The  tech¬ 
nical  architecture  and  product  lines  con¬ 
strain  the  system’s  design  during  the 
system  engineering  process.  The  system 
architecture  emerges  as  an  output  and  is 
constructed  to  satisfy  operational  architec¬ 
ture  requirements  within  the  rules  and 
standards  defined  in  the  technical  archi¬ 
tecture.  Technical  architectures  are  par¬ 
ticularly  important  to  the  systems  engi¬ 
neering  process  because  they  provide  the 
building  codes  for  implementing  systems 


upon  which  engineering  specifications  are 
based,  common  building  blocks  are  built, 
and  product  lines  are  developed.  Note  that 
while  each  of  these  architectures  by  them¬ 
selves  builds  nothing,  together  they  pro¬ 
vide  a  management  tool  that  facilitates 
evolutionary  acquisition  by  supporting 
insertion  of  new  technology,  component 
reuse,  improved  weapon  systems  inter¬ 
operability,  and  the  accommodation  of 
evolving  user  requirements. 

Who  chooses  the  technical  architec¬ 
ture?  Does  the  government  choose  the 
architecture,  does  industry  choose  the 
architecture,  or  is  the  architecture  chosen 
in  concert?  The  government  may  specify 
key  performance  attributes  of  system  build¬ 
ing  blocks  including  internal  interface  stan¬ 
dards.  But  doing  so  without  adequate  input 
from  industry  stifles  innovation,  limits 


Figure  %.  Architectures  and  the  Systems  Engineering  Process 
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performance,  and  increases  cost  by  at¬ 
tempting  to  substitute  our  wisdom  for 
that  of  the  designer.  If,  on  the  other 
hand,  we  provide  no  guidance,  we  may 
encourage  development  of  proprietary 
architectures,  interfaces,  and  compo¬ 
nents.  That  would  leave  DoD  in  a  posi¬ 
tion  where  it  must  maintain  and  modify 
a  unique  product  with  a  single  supplier 
at  a  high,  noncompetitive  price.  Each 
program  must  choose  a  path  between 
these  two  extremes.  A  desirable  situation 
is  for  consensus  among  potential  prime 
contractors  and  their  key  suppliers  on 
application  of  widely  accepted  standards. 

Using  an  open  systems  approach  to  the 
systems  engineering  process  helps  achieve 
an  integrated  design  solution  that  is  resil¬ 
ient  to  changes  in  technology  throughout 
the  life  of  the  system.  Open  systems 


engineering  achieves  this  resiliency  in  life- 
cycle  supportability  by  engineering  sys¬ 
tems  according  to  the  following  principles 
and  practices  (Figure  3): 

•  Identify  as  critical  the  interfaces  to  sub¬ 
systems  or  components  that  are  likely 
to  change  due  to  their  dependence  on 
rapidly  evolving  technology,  are  likely 
to  have  increasing  requirements,  have 
high  replacement  frequency,  or  have 
high  costs.  Such  components  present 
both  the  highest  obsolescence  risks  and 
the  greatest  opportunity  for  future 
technology  insertion. 

•  Use  open  standards  for  these  critical 
interfaces  that  are  supported  by  the 
broader  community,  that  are  considerate 
of  life-cycle  support  requirements,  that 


Figure  3.  Open  Systems  Analysis  for  Integrated  Design  Solution 
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permit  evolution  with  advances  in 
technology,  and  that  support 
technology  insertion. 

•  Use  a  modular  design  approach  com¬ 
bined  with  well-defined  standards- 
based  interfaces  among  modules  to  iso¬ 
late  the  effects  of  change  in  evolving 
systems,  serving  to  reduce  the  need  for 
redesign  as  the  system  is  upgraded. 

•  Identify  the  lowest  level  at  which  the 
government  maintains  control  over  the 
interface  standard,  and  anticipate  how 
this  level  may  change  over  time.  Below 
this  level  the  contractor  is  permitted  to 
use  its  best,  perhaps  proprietary,  prac¬ 
tices  to  improve  or  discriminate  its 
product  in  the  marketplace. 

•  Verify  all  performance  requirements 
and  reevaluate  their  stringency.  Real- 
location  of  requirements  as  necessary 
to  permit  the  wider  use  of  open 
standards  throughout  the  system. 

•  Implement  consistent  conformance 
management  practices  to  ensure  that 
products  procured  for  the  system  con¬ 
form  to  the  established  profile,  to  pre¬ 
vent  limitation  to  one  supplier  who 
might  unilaterally  extend  that  interface. 

The  key  to  achieving  the  benefits  of 
open  systems  designs  lies  in  making  open 
systems  an  integral  part  of  the  classic 
systems  engineering  process  and  in  apply¬ 
ing  open  systems  at  all  stages  of  the  prod¬ 
uct  life  cycle.  The  open  systems  approach 
to  design  will  never  replace  or  make 
obsolete  that  process — if  anything,  it 
demands  that  the  process  be  even  more 
rigorously  applied.  As  Figure  4  shows, 


each  of  the  major  aspects  of  the  systems 
engineering  process  must  include  consid¬ 
eration  of  open  systems  design  concepts 
and  principles. 

Requirements  analysis  must  empha¬ 
size  the  balancing  of  business  goals  (costs, 
common  use,  life-cycle  supportability, 
etc.)  with  technical  goals  (functionality, 
performance,  interfaces,  and  other  con¬ 
straints).  As  the  systems  engineering  pro¬ 
cess  iterates,  the  requirements  analysis 
step  is  revisited  to  consider  cost-perfor¬ 
mance  tradeoffs  to  meet  most  performance 
objectives  while  achieving  as  large  as 
possible  reductions  in  life-cycle  costs.  The 
stringency  of  requirements  is  reevaluated 
to  consider  the  use  of  open  standards  for 
interfaces  as  performance  requirements 
are  balanced  (weighed)  against  business 
requirements.  To  do  this,  engineers  need 
to  be  better  trained  to  incorporate  life- 
cycle  cost  in  design  and  to  be  provided 
with  tools  that  allow  them  to  rapidly  assess 
life-cycle  cost  impacts.  Under  any  circum¬ 
stances,  users  need  systems  that  are 
supportable  and  affordable,  and  these 
requirements  demand  that  one  consider 
open  architectures  as  system  elements  are 
defined. 

Functional  analysis  and  allocation 

must  define  an  architecture  that  provides 
a  framework  for  identifying  interfaces 
critical  to  achieving  system  business  and 
technical  performance  goals.  Require¬ 
ments  should  be  allocated  with  a  view 
toward  achieving  functional  modularity. 
Functional  modularity  can  facilitate  physi¬ 
cal  modularity  and  the  use  of  open  inter¬ 
faces  to  support  system  evolution  goals. 
As  the  systems  engineering  process 
iterates,  this  step  is  revisited  to  allocate 
functionality,  to  modularize  those  compo¬ 
nents  or  subsystems  that  are  dependent  on 
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Process  Input 

Technical  architecture 
Product  lines 

Customer  needs,  objectives,  and  requirements 

-  Missions 

-  Measures  of  effectiveness 

-  Environments 

-  Constraints 
Technology  base 

Output  requirements  from  prior  development  effort 
Program  decision  requirements 

Requirements  applied  through  specifications  and  standards 


Requirements  Analysis 

•  Analyze  business  goals  _ _ 

(costs,  common  use, 
scalability,  etc.)  and 
performance  goals. 

Requirements  Loop  y 

Functional  Analysis  and  Allocation 

Define  an  architecture  that  identifies 

critical  interfaces 

Define  “level  of  openness” 

Apply  modularity 

Re-evaluate  “stringency"  of  requirements 
Consider  reallocation  of  performance 
or  business  requirements 


Design  Loop 


Synthesis 


System  Analysis 
and  Control 
(Balance)  > 


Conformance  Management 

Tradeoff  studies 
Effectiveness  analyses 
Risk  management 
Configuration  management 
Interface  management 
Data  management 
Performance  measurement 

-  SEMS 

-  TPM 

-  Technical  reviews 


Make  implementation  decisions  based  on  market  research 
Prototype  to  delay  implementation  decisions 
Standardize  on  interfaces,  not  products 
Build  strategic  supplier  relationships  with  vendors 
Develop  relationship  with  standards  community 


Related  Terms 

Customer  =  Organizations  responsible  for  primary 
functions 

Primary  functions  =  Development,  manufacturing, 
verification,  deployment,  operations,  support, 
training,  disposal 

System  elements  =  Hardware,  software,  personnel, 
facilities,  data,  material,  services,  techniques 


Process  Output 

System  architecture 
Development  level  dependent 

-  Decision  data  base 

-  System/configuration  item 
architecture 

-  specifications  and  baselines 


Figure  4* 

Integrating  Open  Systems  and  the  Systems  Engineering  Process 
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rapidly  evolving  technology,  have  high 
replacement  frequency  or  are  high  cost, 
and  to  reallocate  performance  or  business 
requirements  as  necessary  to  allow  for  the 
use  of  open  interface  standards  during 
synthesis. 

Synthesis  and  design  should  continue 
the  search  for  alternative  system  architec¬ 
tures  that  will  satisfy  requirements.  To  be 
effective,  good  design  synthesis  demands 
an  iterative  approach  that  involves  revis¬ 
iting  the  functional  allocations  and  devel¬ 
oping  alternative  physical  solutions  until 
a  balanced  design  (in  terms  of  cost,  per¬ 
formance,  and  risk)  is  achieved.  Modu¬ 
larity  should  be 


"To  be  effective, 
good  design  synthe¬ 
sis  demands  an 
iterative  approach 
that  involves  revis- 


used  in  system 
design  where 
interfaces  be¬ 
tween  modules 
are  based  on 


iting  the  functional  open,  widely 


allocations  and  supported  inter- 

developing  alferna-  face  standards. 


five  physical  solu¬ 
tions  until  a  bal¬ 
anced  design 
(in  terms  of  cost, 
performance,  and 
risk)  is  achieved. " 


Modularity 
should  be  based 
on  well-defined 
interfaces  to 
isolate  compo¬ 
nents  that  are 


likely  to  change 
over  time  (e.g.,  those  dependent  on  rap¬ 
idly  evolving  technology  or  that  have  high 
replacement  frequency)  or  are  high  cost, 
since  these  components  present  the  high¬ 
est  obsolescence  risks  and  the  greatest 
opportunity  for  future  technology  inser¬ 
tion.  Well-defined  interfaces  are  used  to 
decouple  system  components  and  define 
firewalls  to  contain  evolution  of  lower 
level  component  upgrades  and  modifica¬ 
tions,  thereby  minimizing  future  redesign, 
and  possibly  retesting,  when  components 


are  upgraded.  In  addition,  physical  modu¬ 
larity  should  be  aligned  with  functional 
partitioning  to  facilitate  the  replacement 
of  specific  subsystems  and  components 
without  impacting  others. 

Design  iteration  should  sequentially 
reconsider  the  allocations  of  function  and 
performance  that  define  the  design 
requirements  for  each  system  component 
with  the  objective  of  achieving  user 
(customer)  requirements  within  an  opti¬ 
mal  open  systems  solution.  From  an  open 
systems  perspective,  if  this  sequential 
iteration  is  stopped  as  soon  as  the  first 
acceptable  technical  solution  is  achieved, 
there  are  two  probable  results:  either  the 
solution  will  be  shown  to  require  unique 
designs  that  require  new  development,  or 
an  open  solution,  if  imposed  at  this  point, 
will  likely  not  meet  all  the  requirements 
of  the  user.  However,  in  most  cases,  a  final 
design  can  almost  certainly  be  developed 
that  results  in  system  architectures  that  in¬ 
clude  some  items  that  are  open  and  other 
elements  that  are  not.  Although  open 
designs  are  the  objective,  it  is  neither  nec¬ 
essary  nor  in  some  cases  even  possible  that 
every  element  or  item  of  most  complex 
systems  be  totally  open. 

Systems  analysis  and  control  must 
include  conformance  management ,  incor¬ 
porating  both  implementation  and  appli¬ 
cations  conformance  testing.  The  selected 
conformance  approach  must  be  fully 
defined  and  documented  so  that  it  is 
understood  by  all  parties.  The  degree  to 
which  open  systems  benefits  can  be 
achieved  will  depend  largely  on  how  well 
the  product  design  conforms  to  selected 
standards.  Completely  defined  interface 
profiles  will  allow  vendors  to  build  stan- 
dards-based  components  and  allow  users 
to  design  systems  to  use  standard s-based 
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components.  In  all  cases,  candidate  com¬ 
ponents  should  be  tested  against  detailed 
system  profiles  to  ensure  that  components 
conform  to  profiles. 

Open  System  Design  Challenges 

The  open  approach  to  system  design 
offers  considerable  benefits,  already  dis¬ 
cussed,  in  terms  of  life-cycle  support, 
affordability,  and  timely  technology  inser¬ 
tion.  The  approach  also  carries  with  it 
some  substantial  differences  in  the  way 
that  systems  will  be  managed  and  sup¬ 
ported.  Since  by  its  nature  open  systems 
designs  will  involve  increased  use  of  com¬ 
mercial  and  nondevelopmental  items  in 
systems  architectures,  the  government  will 
necessarily  have  to  plan  for  significant 
differences  in  the  way  systems  are  man¬ 
aged  from  a  technical  perspective.  These 
differences  cut  across  almost  every  aspect 
of  engineering  management,  and  while 
space  prohibits  an  exhaustive  treatment, 
examples  include  the  following: 

•  Standards-based  architectures  lessen 
the  degree  of  control  that  DoD  can 
expect  to  exert.  Changes,  fixes,  and 
updates  will  likely  be  under  the 
vendor’s  control.  This  can  have  a 
significant  impact  on  system  support. 

•  Standards-based  elements  of  the  archi¬ 
tecture  are  likely  to  be  faster  and 
cheaper  to  acquire  than  a  comparable 
developmental  item  but  may  take  more 
time  to  integrate  and  test. 

•  Standards  selection  is  risky.  Acquisi¬ 
tion  will  require  substantially  more 
knowledge  of  the  current  state  of  the 


art  and  the  marketplace  on  the  part  of 
the  government. 

•  Standards  evolve  with  time.  It  is  diffi¬ 
cult  to  project  the  extent  to  which  a 
given  standard  will  endure.  It’s  equally 
challenging  to  determine  when  to  move 
from  one  standard  to  the  next. 

•  Standards-based  architectures  tend  to 
change  the  focus  of  systems  engineer¬ 
ing  from  design  to  integration.  The 
challenge  is  to  achieve  performance 
requirements  without  detailed 
control  over  the  component  design 
specification. 

•  An  item,  once  integrated,  may  affect 
other  system  parameters.  Commercial 
and  nondevelopmental  items  make 
testing  an  ongoing  and  continuing 
activity  to  verify  that  items  can 
integrate  successfully  into  systems. 

•  The  use  of  commercial  and  nondevel¬ 
opmental  items  requires  that  support 
concepts  be  developed  early  in  the 
acquisition  cycle. 

While  this  is  hardly  an  exhaustive  list, 
it  makes  the  point  that  open  systems  engi¬ 
neering  introduces  new  issues  into  the 
management  of  the  technical  aspects  of 
programs.  There  are  many  potential  ben¬ 
efits,  but,  likewise,  there  are  challenges 
and  problems  that  the  manager  must  be 
alert  to  anticipate  and  overcome. 

Summary 


The  objective  of  open  systems  acquisi¬ 
tions  is  to  provide  the  warfighter  with  the 
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most  effective  weapon  systems  possible. 
An  open  systems  approach  to  systems 
engineering  facilitates  this  throughout 
the  life  of  the  system.  Open  systems 
designs  provide  an  opportunity  to  achieve 
affordable  designs  that  can  more  readily 
accommodate  changing  technology  while 
promoting  multiple  sources  of  supply; 
however,  to  achieve  good  open  systems 
designs  first  demands  that  a  disciplined 
systems  engineering  approach  be  taken  to 
define  the  appropriate  elements  in  the 
system  to  be  opened. 

Most  systems  will  not  be  completely 
open  in  their  architectures,  but  a  well- 
engineered  design  will  result  in  a  design 
strategy  that  takes  maximum  advantage  of 
the  benefits  available  from  opening  the 
design.  Associated  with  an  open  approach 
is  the  need  to  focus  on  and  manage  the 
interfaces  between  open  system  elements 


and  other  elements  of  the  system.  Choos¬ 
ing  well-known  and  accepted  industry 
standards  and  applying  them  in  a  con¬ 
trolled  manner  will  go  far  toward  achiev¬ 
ing  the  desired  results.  Overall,  the  sys¬ 
tem  architecture  resulting  from  a  system 
engineering  process  should  be  linked  to  a 
business  case  analysis.  Architecture  deci¬ 
sions  should  be  traceable  to  performance, 
life-cycle  cost,  schedule,  and  risk.  The 
alternatives  for  support,  maintenance,  and 
upgrade  should  be  evaluated. 

For  maximum  benefit,  an  open  systems 
approach  should  focus  on  planned  use  of 
designs  across  a  system  or  domain.  As 
designs  are  opened,  managers  must  be 
aware  of  the  fact  that  support  and  acquisi¬ 
tion  strategies  will  necessarily  be  affected. 
These  impacts  must  be  anticipated  and 
planned  for  from  the  outset  during  system 
design. 
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Lessons  Learned 


AN  INVESTMENT-BASED 
APPROACH  FOR  MANAGING 
SOFTWARE-INTENSIVE 
SYSTEMS 

Margaret  E.  Myers 


Maintaining  information  superiority  will  be  vital  to  the  21st-century  warfighter, 
and  the  military’s  documented  shortcomings  in  acquiring  leading-edge 
information  technology  systems  must  be  addressed  in  order  to  meet  this  need. 
The  investment-based  approach  to  the  acquisition  of  software-intensive 
systems  discussed  here  considers  recent  management  reform  legislation  and 
will  help  DoD  meet  information  superiority  requirements. 


In  spite  of  numerous  studies  document¬ 
ing  the  problems  encountered  in  the 
acquisition  of  software-intensive  sys¬ 
tems,  the  defense  acquisition  community 
has  not  fully  implemented  the  recommen¬ 
dations  from  those  studies.  As  a  result,  the 
acquisition  problems  persist.  Yet  today’s 
national  security  environment  demands 
even  more  flexibility  and  responsiveness 
from  the  defense  acquisition  process,  with 
software-intensive  systems  often  on  the 
leading  edge  of  both  the  Revolution  in 
Military  Affairs  and  the  Revolution  in 
Business  Affairs.  This  article  recasts  some 
of  the  historical  recommendations  in  the 
light  of  recent  management  reform  legisla¬ 
tion  and  describes  an  investment-based  man¬ 
agement  approach  to  the  acquisition  of 


software-intensive  systems.  Although  the 
concepts  described  here  are  applicable  to 
both  hardware  and  software  development, 
the  scope  of  this  article  is  limited  to  the  man¬ 
agement  of  systems  with  extensive  soft¬ 
ware  components,  to  include  command 
and  control  systems,  automated  information 
systems,  and  other  information  technology 
investments. 

Why  Change  Is  Needed 


The  document  Joint  Vision  2010  (Chair¬ 
man  of  the  Joint  Chiefs  of  Staff,  1996)  de¬ 
scribes  the  future  direction  of  our  joint 
warfighting  forces  based  on  the  emerging 
operational  concepts  of  dominant 
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maneuver,  precision  engagement,  focused 
logistics,  and  full-dimension  protection. 
Execution  of  these  concepts  depends  on 
our  ability  to  achieve  and  maintain 
information  superiority  (CJCS,  1996): 

Sustaining  the  responsive,  high- 
quality  data  processing  and  infor¬ 
mation  needed  for  joint  military 
operations  will  require  more  than 
just  an  edge  over  an  adversary.  We 
must  have  information  superior¬ 
ity:  the  capability  to  collect, 
process,  and  disseminate  an 
uninterrupted  flow  of  information 
while  exploiting  or  denying  an 
adversary’s  ability  to  do  the  same. 

The  Department  of  Defense  (DoD) 
Acquisition  Year  2000  goal  (Gore,  1997) 
of  delivering  new  major  defense  systems 
to  the  users  in  25  percent  less  time  is 
especially  relevant  to  implementation  of 
Joint  Vision  2010,  which  depends  heavily 
on  DoD’s  ability  to  leverage  new  and 
emerging  technological  opportunities. 
Unfortunately,  the  department’s  track 
record  in  keeping  up  with  the  rapid  pace 
of  advances  in  commercial  information 
technology  (IT)  is  not  good,  and  many 
software-intensive  systems  fail  to  achieve 
their  key  performance  parameters. 

Although  defense  acquisition  policy  has 
evolved  from  the  time  when  major  defense 
acquisition  programs  were  mostly  hard¬ 
ware,  the  acquisition  process  still  often 
requires  extensive  tailoring  for  software¬ 
intensive  systems.  However,  very  little 
guidance  is  available  on  how  to  tailor  the 
policy  for  these  systems.  (See  Appendix 
A  for  descriptions  of  various  acquisition 
and  software  development  models.)  A 
different  approach  is  needed  for  software¬ 


intensive  systems,  which  must  keep  pace 
with  technological  advances  while  being 
responsive  to  the  warfighter. 

Implementing  the  management  approach 
described  here  will  support  information 
superiority  requirements  by  delivering 
software-intensive  systems  that  are  more 
responsive  to  the  needs  of  the  21st  century 
warfighter. 

Proposed  Management  Approach 

The  following  recommendations  are 
based  on  an  analysis  of  various  acquisi¬ 
tion  and  development  models,  legislation, 
policy  guidance,  and  best  practices 
relevant  to  software-intensive  systems. 
The  recommendations  focus  primarily  on 
changes  to  the  management  and  oversight 
processes  since  the  technical  implemen¬ 
tation  will,  of  necessity,  vary  from  system 
to  system. 

Adopt  an  Investment  Focus 

For  most  acquisition  programs,  success 
is  defined  in  terms  of  gaining  Milestone 
III  approval  to  produce  and  deploy  the 
system,  which  is  essentially  a  one-time 
event.  A  more  appropriate  perspective  for 
software-intensive  systems  may  be  to  view 
them  as  evolving  capital  assets  that  will 
provide  a  needed  capability  for  some  num¬ 
ber  of  years.  For  software-intensive  sys¬ 
tems,  that  capability  will  be  delivered 
incrementally  to  the  user  over  the  life  of 
the  investment.  The  key  is  to  develop  a 
long-term  investment  focus  in  support  of 
goals  that  span  the  life  of  the  program,  not 
just  to  deliver  a  one-time  product  and  walk 
away.  This  capital  asset  perspective  is 
consistent  with  the  Government  Perfor¬ 
mance  and  Results  Act  (1993)  and  Office 
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of  Management  and  Budget  (OMB) 
capital  planning  guidance.  (For  more 
information  on  GPRA  and  the  OMB 
Capital  Planning  Guide  [OMB,  1997],  see 
Appendix  B.) 

Define  Investment  Objectives 

For  DoD  systems,  the  value  of  a  capi¬ 
tal  asset  should  be  measured  in  terms  of 
its  contribution  toward  achieving  one  or 
more  goals  in  the  DoD  strategic  plan  (cur¬ 
rently  the  Quadrennial  Defense  Review 
[QDR])  (Cohen,  1997).  Given  the  pro¬ 
posed  “evolving  capital  asset’"  perspective 
described  above,  the  requirements  and 
acquisition  communities  should  jointly 
develop  intermediate  investment  objec¬ 
tives  that  are  acceptable  to  the  user  and 
technically  feasible.  The  acquirer  subse¬ 
quently  translates  these  objectives  into 
capability  packages  that,  when  deployed, 
demonstrate  measurable  progress  toward 
meeting  the  DoD  strategic  goals.  The  sys¬ 
tem  developer  derives  the  specific  tech¬ 
nical  requirements  for  each  capability 
package  based  on  the  user’s  objectives. 
When  deployed,  each  capability  package 
should  demonstrate  measurable  progress 
toward  achieving  the  intermediate  objec¬ 
tives  and,  ultimately,  the  strategic  goals. 

The  key  is  for  management  to  be  able 
to  maintain  traceability  from  the  Joint 
Vision  2010  concepts,  to  the  DoD  strate¬ 
gic  plan  and  supporting  strategic  goals,  to 
the  investment  objectives,  and  finally  to 
the  implementing  capability  packages. 
The  challenge  lies  in  defining  invest¬ 
ment  objectives  that  are  measurable  and 
preferably  quantifiable.  The  health  affairs 
community  is  probably  the  leader  in 
holding  its  management  accountable  by 
measuring  progress  against  strategic  goals 
and  investment  objectives.  Defining 


system-level  objectives  and  linking  them 
to  corporate  strategic  goals  are  key  tenets 
from  the  GPRA,  Clinger-Cohen  Act  of 
1996,  and  OMB  guidance.  (See  Appendix 
B  for  more  information  on  the  Clinger- 
Cohen  Act.) 


Build  an  Investment  Framework 

The  decision  to  invest  in  a  software¬ 
intensive  capital  asset  should  initiate 
planning  for  an  investment  framework 
(business  model)  to  manage  that  asset 
during  its  useful  life.  This  framework 
should  include  not  only  the  operational 
and  technical  architectures  that  will  define 
how  the  capital  asset  will  be  used  and  built, 
but  also  repeatable  processes  for  updat¬ 
ing  the  investment  objectives,  negotiating 
the  scope  of  each  increment,  evolving  the 
software  com¬ 
ponents,  man¬ 
aging  the  risks, 
and  measuring 
the  outcomes. 

For  deeply  em¬ 
bedded  applica¬ 
tions,  a  DoD- 
driven  domain 
analysis  and 

architecture  are  essential,  with  an  empha¬ 
sis  on  classic  software  reuse  paradigms; 
for  many  information  systems,  a  market- 
driven  analysis  and  architecture  that  can 
leverage  the  commercial  sector  may  be 
more  appropriate.  For  command  and  con¬ 
trol  systems,  a  hybrid  approach  is  usually 
required  to  deal  with  acquiring  and  inte¬ 
grating  commercial-off-the-shelf  (COTS) 
and  government-off-the-shelf  (GOTS) 
applications  into  custom-developed  soft¬ 
ware.  Some  of  the  challenges  for  hybrid 
systems  include  modification  of  COTS 
packages  to  interoperate  with  custom- 


"The  challenge 
lies  In  defining 
investment  ebjec* 
fives  that  are 
measurable  and 
preferably 
quantifiable/7 


63 


Acquisition  Review  Quarterly — Winter  1999 


developed  software;  the  resulting  mainte¬ 
nance,  licensing,  and  ownership  issues; 
synchronization  of  changes  with  existing 
GOTS  software  that  will  continue  to 
evolve  independently;  and  ground  rules 
for  each  increment  to  retain  maximum 
flexibility  for  future  design  and  require¬ 
ments  changes. 

From  a  management  and  oversight  per¬ 
spective,  building  the  investment  frame¬ 
work  to  support  the  production  of  follow- 
on  increments  should  be  just  as  important 
as  deploying  the  first  increment.  The 
investment  framework  is  analogous  to 

establishing  a 
software  pro¬ 
duction  line  to 
streamline  the 
development  of 
following  incre¬ 
ments;  this  ap¬ 
proach  was  suc¬ 
cessfully  dem¬ 
onstrated  in  the 
Software  Technology  for  Adaptable,  Re¬ 
liable  Systems  (STARS)  project  sponsored 
by  the  Defense  Advanced  Research 
Project  Agency  (Institute  for  Defense 
Analysis,  1996).  The  concept  of  an  invest¬ 
ment  framework  is  consistent  with  the 
Clinger-Cohen  Act,  which  mandates  an 
integrated  technology  architecture.  (For 
more  information  on  architectures  for 
software-intensive  systems,  see  Appendix 
C;  for  more  information  on  software 
product  lines,  see  Appendix  A.) 


"The  goal  should  be 
to  deliver  small, 
compatible 
increments  that 
provide  useful, 
added  capability 
every  6  to  18 
months." 


of  which  solves  a  specific  part  of  an  over¬ 
all  mission  problem  and  delivers  a  mea¬ 
surable  net  benefit  independent  of  future 
segments”  (Raines,  1996).  One  of  the 
lessons  learned  from  program  managers 
who  have  implemented  software-intensive 
systems  based  on  the  incremental  or 
evolutionary  models  is  that  the  first 
increment  typically  fails  to  meet  its  cost, 
schedule,  and  performance  parameters 
because  the  scope  is  too  broad.  This  usu¬ 
ally  happens  because  the  user  is  unwill¬ 
ing  to  constrain  the  requirements  because 
of  fears  that  follow-on  increments  won’t 
be  delivered. 

Adopting  a  capital  asset  perspective  and 
constraining  increment  size  should  shift 
the  focus  from  one  of  demanding  full 
capability  in  the  first  increment  to  defin¬ 
ing  the  minimum  useful  capability  for  the 
first  and  each  subsequent  increment.  The 
goal  should  be  to  deliver  small,  compat¬ 
ible  increments  that  provide  useful,  added 
capability  every  6  to  18  months.  The 
Global  Command  and  Control  System 
(GCCS),  for  example,  is  currently  on  an 
18-month  schedule  for  deploying  major 
releases,  with  smaller  beta  releases  in- 
between.  The  Army  Tactical  Command 
and  Control  System  (ATCCS)  currently 
plans  to  deploy  new  software  increments 
approximately  every  12  months.  Smaller 
increments  reduce  risk,  minimize  sched¬ 
ule  delays,  and  avoid  cost  overruns.  This 
is  consistent  with  the  Clinger-Cohen  Act 
and  OMB  guidance. 


Constrain  Increment  Size 

A  tenet  of  recent  legislation  and  guid¬ 
ance  is  that  information  technology  sys¬ 
tems  should  “be  implemented  in  phased, 
successive  segments  as  narrow  in  scope 
and  brief  in  duration  as  practicable,  each 


Apply  the  Spiral-to-Circle  Model 

Rechtin  and  Maier  (1997)  discuss  the 
differences  between  the  waterfall  model, 
which  aptly  fits  the  largely  irreversible 
steps  of  hardware  acquisition,  and  the 
spiral  model,  which  better  represents  the 
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iterative  process  of  software  development 
(Figure  1).  Although  current  defense 
acquisition  policy  strongly  supports 
tailoring,  most  acquisition  strategies 
resemble  the  waterfall  model  rather  than 
the  spiral  model.  After  analyzing  the  struc¬ 
tural  dissimilarities  between  the  two 
models  and  the  problems  that  result  when 
coordinating  hardware  and  software 
development,  Rechtin  and  Maier  recom¬ 
mend  use  of  a  single  spiral-to-circle  model 
(Figure  2). 

This  model  is  based  on  the  following 
heuristic:  “Complex  systems  will  develop 
and  evolve  within  an  overall  architecture 
much  more  rapidly  if  there  are  stable  in¬ 
termediate  forms  than  if  there  are  not/’  For 
software  development,  the  spiral-to-circle 
model  implies  pausing  on  the  outward 


spiral  by  entering  a  closed  circle  for  a 
stable  version,  which  could  be  deployed 
and  which  would  form  the  baseline  for  the 
next  increment  of  functionality.  For  hard¬ 
ware  development,  the  model  implies  a 
hold  after  each  step  to  review  progress. 
For  combined  hardware  and  software  de¬ 
velopment,  the  closed  circles  represent  the 
points  at  which  stable  hardware  and  soft¬ 
ware  configurations  come  together  for 
testing  and  potential  deployment. 

The  spiral-to-circle  model  appears  to  be 
a  useful  management  tool  whenever  it  is 
necessary  to  integrate  hardware  and  soft¬ 
ware  components  in  the  same  system.  The 
model  is  also  applicable  to  hardware¬ 
intensive  systems  that  are  developed  using 
simulation-based  acquisition  methodolo¬ 
gies.  Additionally,  the  model  should  be  a 
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Source:  The  Art  of  Systems  Architecting,  by  E.  Rechtin  and  M.  Maier,  1997,  CRC  Press. 


Figure  1.  Waterfall  and  Spiral  Models 
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Figure  2.  The  Spiral-to-Cir«le  Model 


useful  integration  tool  when  commercial  approach  must  address  three  areas  related 
items  or  other  nondevelopmental  items  are  to  investment  management  of  software- 
used  in  lieu  of  developing  new  components.  intensive  capital  assets.  First,  are  the  man- 
(For  more  information  on  the  spiral-to-  agement  issues  associated  with  designing, 
circle  model,  see  Appendix  A.)  developing,  and  deploying  the  core 

increment  that  will  provide  the  initial 
operating  capability?  Second,  are  the 

Investment  Management  Issues  issues  associated  with  managing  the  foi- 

- - - - - -  low-on  increments?  (These  issues  endure 

The  investment-based  approach  just  for  the  life  of  the  system.)  Third,  are  the 
described  (adopt  an  investment  focus,  interoperability  issues  that  arise  m  coordi- 
define  investment  objectives,  build  an  nating  the  design,  development  and 
investment  framework,  constrain  incre-  deployment  of  increments  from  multiple 
ment  size,  and  apply  the  spiral-to-circle  systems  (systems  of  systems), 
model)  is  intended  to  support  information 

superiority  requirements  by  delivering  INCREMENT  ISSUES 

software-intensive  systems  that  are  more  Adopting  the  capital  asset  investment 
responsive  to  the  needs  of  the  21st-cen-  approach  with  its  emphasis  on  up-front  plan- 

tury  warfighter.  To  accomplish  this,  the  ning  will  require  increased  participation 
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from  the  requirements  (user)  community, 
especially  in  defining  the  investment 
objectives  and  constraining  increment 
size.  One  way  to  ease  this  burden  would 
be  to  appoint  an  acquisition-qualified 
program  manager  to  coordinate  the  plan¬ 
ning  activities  before  the  investment  is 
approved  as  an  acquisition  program.  This, 
in  turn,  would  require  some  additional  train¬ 
ing  for  the  program  manager  and  might  con¬ 
flict  with  current  initiatives  to  reduce  the 
size  of  the  acquisition  workforce. 

Building  the  investment  framework  is 
not  trivial.  The  GCCS  evolutionary  acqui¬ 
sition  process  appears  cumbersome  to 
those  who  see  it  for  the  first  time,  but  it 
was  invented  by  the  GCCS  integrated 
product  team  members  (who  received  the 
Defense  Acquisition  Executive  Award  for 
Acquisition  Excellence  for  their  initia¬ 
tive),  and  it  seems  to  work  effectively  for 
GCCS.  Unless  the  investment  framework 
processes  for  other  programs  are  carefully 
established  and  the  people  are  effectively 
trained,  the  software-intensive  capital 
asset  concept  is  no  better  than  current 
acquisition  approaches.  (For  additional 
information  on  GCCS,  see  Appendix  C.) 

Follow-on  Increment  Issues 

Once  the  investment  framework  is 
effectively  established  and  has  been 
proven  to  work  on  the  first  increment, 
follow-on  increment  development  should 
have  lower  risk,  especially  if  the  incre¬ 
ments  are  schedule-constrained.  The 
Milestone  Decision  Authority  should  con¬ 
sider  delegating  follow-on  deployment 
decisions,  but  some  limited  oversight  may 
be  required  to  ensure  that  the  process 
remains  disciplined. 

Software-intensive  systems  that  have 
already  deployed  their  core  increment  are 


candidates  for  conversion  to  the  invest¬ 
ment  approach  once  they  have  established 
an  appropriate  investment  framework,  to 
include  a  current  baseline.  The  GCCS  evo¬ 
lutionary  acquisition  process,  for  example, 
was  developed  after  the  core  increment 
was  deployed. 


Systems  of  Systems  Issues 

The  investment  framework  must 
include  a  process  for  ensuring  interoper¬ 
ability  with  other  systems  and  increments 
from  other  software-intensive  capital 
assets.  This  is  especially  critical  in  sup¬ 
porting  the  Joint  Vision  2010  requirement 
for  information  superiority.  The  Army  uses 
the  spiral-to-circle  model  to  address  syn¬ 
chronization  issues  associated  with  the 
Army  Battlefield  Control  System  (ABCS). 
The  ABCS  com¬ 
ponent  systems 
must  success¬ 
fully  complete  a 
synchronization 
event  to  demon¬ 
strate  interoper¬ 
ability  before 
deployment. 

Beta  sites  and 
test  beds  are 
also  useful  tools 

for  validating  interoperability  before 
deployment.  Constraining  increment  size 
should  be  conducive  to  scheduling  syn¬ 
chronization  events  and  establishing 
OT&E  test  windows,  in  which  multiple 
systems  have  an  opportunity  to  jointly  test 
their  newest  increments  before  full 
deployment.  (For  more  information  on 
operational  test  and  evaluation  [OT&E] 
strategies  for  software-intensive  systems, 
see  Appendix  C.) 


"The  investment 
framework  must 
include  a  process 
for  ensuring 
interoperability 
with  other  systems 
and  increments ■v:#.-" 
from  other  software* 
intensive  capital 
assets." 
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Process  Changes  Required 
for  Implementation 


Implementing  the  investment-based 
approach  described  here  will  require 
acquisition,  requirements,  and  PPBS  pro¬ 
cess  changes,  to  include  changes  in  policy, 
guidance,  and  training. 


Acquisition  Process 

The  recommendations  suggested  above 
are  consistent  with  defense  acquisition 
policy,  which  allows  for  extensive  tailor¬ 
ing.  However,  the  proposed  approach 
should  be  documented  in  the  Defense 


Acquisition  Deskbook  (DAD,  1998)  as  a 
DoD-wide  best  practice  and  updated  with 
implementation  lessons  learned. 

Implementing  the  concepts  described 
above  will  not  work  without  an  investment 
in  education  and  training  for  program 
managers,  their  staffs,  and  other  person¬ 


nel  in  the  acquisition  chain.  Team  train¬ 
ing  for  the  participants  in  each  specific 
project  may  be  the  most  efficient  way  to 

introduce  these 

"The  acquisition  ”ew  concepts, 

community  must  SPeclflc  t0Plcs 


partner  with  the 
loint  Staff  to  jointly 
Identify  needed 
changes  to  the 
requirements 
process  in  support  of 
the  software¬ 
intensive  capital 
asset  approach." 


that  must  be  ad¬ 
dressed  include 
the  GPRA,  the 
Clinger-Cohen 
Act,  OMB  capi¬ 
tal  asset  guid¬ 
ance,  architec¬ 
tures,  and  soft¬ 
ware  manage¬ 


ment  issues,  to 
include  the  use  of  software  process  and 


product  quality  measures.  The  Software 
Engineering  Institute’s  software  capabil¬ 
ity  maturity  model  (CMM)  and  software 


acquisition  CMM  are  examples  of  models 
that  can  be  used  to  promote  the  process 
improvements  needed  to  build  and 
manage  an  investment  framework. 

Requirements  Process 

The  acquisition  community  must  part¬ 
ner  with  the  Joint  Staff  to  jointly  identify 
needed  changes  to  the  requirements  pro¬ 
cess  in  support  of  the  software-intensive 
capital  asset  approach.  One  of  the  key 
lessons  learned  and  relearned  in  the 
acquisition  of  software-intensive  systems 
is  the  need  to  involve  the  real  end  user,  both 
in  helping  to  refine  the  specific  requirements 
and  in  assessing  how  well  those  specific 
requirements,  as  they  are  implemented,  meet 
their  needs.  The  GCCS  beta  release  strat¬ 
egy  mentioned  previously  allows  users  to 
experiment  with  new  applications  on  a 
trial  basis;  only  those  applications  that  the 
users  want  are  incorporated  into  the  next 
major  release.  The  GCCS  evolutionary 
acquisition  strategy  supports  this  flexible 
approach  to  requirements  generation,  but 
most  major  acquisition  programs  do  not 
have  this  flexibility. 

Planning,  Programming,  and 
Budgeting  System  (PPBS)  Process 

The  comptroller  and  the  acquisition 
community  should  jointly  identify  needed 
changes  to  the  PPBS  process  to  support 
the  software-intensive  capital  asset 
approach.  To  best  implement  the  approach 
described  here,  program  managers  need  a 
guarantee  of  program  stability  and  a 
steady-state  funding  stream.  The  comp¬ 
troller  should  also  work  with  OMB  to 
ensure  that  the  proposed  investment  pro¬ 
cess  is  implemented  consistently  with 
OMB  guidance. 
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Other  Implementation  Suggestions 

In  addition  to  integrating  necessary 
changes  into  the  acquisition,  requirements, 
and  PPBS  processes,  it  may  be  necessary 
to  charter  a  multifunctional  process  action 
team  to  develop  the  policy,  guidance,  and 
training  required  to  implement  the  pro¬ 
posed  approach.  One  or  more  pilot  pro¬ 
grams  would  be  useful  for  maturing  the 
new  processes  and  demonstrating  the 
improvement. 

Conclusion 


This  investment-based  approach  to  the 
acquisition  of  software-intensive  systems 
meets  information  superiority  requirements, 


while  complying  with  recent  management 
reform  legislation.  The  proposed  approach 
is  based  on  five  key  recommendations: 
adopting  an  investment  focus,  defining 
investment  objectives,  building  an  invest¬ 
ment  framework,  constraining  increment 
size,  and  applying  the  spiral-to-circle 
model.  The  approach  can  be  adapted  to 
address  issues  related  to  core  increments, 
follow-on  increments,  and  systems  of 
systems.  Successful  implementation  will 
require  coordinated  changes  to  the  acqui¬ 
sition,  requirements,  and  PPBS  processes 
and  a  better  understanding  of  how  to  tailor 
acquisition  strategies.  These  changes,  how¬ 
ever,  are  essential  to  delivering  software¬ 
intensive  systems  that  are  more  responsive 
to  the  needs  of  the  21st-century  warfighter. 
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Appendix  A 


Acquisition  and  Software 
Development  Models 


Acquisition  Program  Structure  Models 

The  following  information  is  extracted 
from  the  Defense  Acquisition  Deskbook 
( 1998).  The  program  structure  is  the  fun¬ 
damental  building  block  of  the  program’s 
acquisition  strategy,  where  “program 
structure”  means  the  phases  and  milestone 
decision  points  established  for  a  program. 
The  program  structure  models  described 
below,  when  appropriately  tailored,  are 
suitable  for  the  vast  majority  of  major  pro¬ 
grams.  One  of  the  major  themes  in  the 
current  version  of  the  DoD  5000  policy  is 
that  Milestone  Decision  Authorities 
(MDAs)  “should  strive  to  tailor  most 
aspects  of  the  acquisition  process,  includ¬ 
ing  program  documentation,  acquisition 
phases,  and  the  timing,  scope,  and  level 
of  decision  reviews.” 

Traditional  model.  This  model  is  the 
four-milestone,  four-phase  process  that 
represents  the  department’s  typical 
approach  to  major  acquisition  develop¬ 
ment  programs.  Because  of  its  widespread 
use,  statutory  requirements  tend  to  be 
associated  with  this  model’s  phases  and 
milestone  decision  points. 

Grand  design  model.  This  model  is 
characterized  by  acquisition,  develop¬ 
ment,  and  deployment  of  the  total  opera¬ 
tional  capability  in  a  single  increment.  The 
required  operational  capability  can  be 
clearly  defined  and  further  enhancement 
is  not  foreseen  to  be  necessary.  The  grand 
design  model  is  most  appropriate  when  the 
user  requirements  are  well  understood, 
supported  by  precedent,  easily  defined, 


and  assessment  of  other  considerations 
(e.g.,  risks,  funding,  schedule,  size  of  pro¬ 
gram,  or  early  realization  of  benefits) 
indicates  that  a  phased  approach  is  not 
required. 

Incremental  model.  The  incremental 
model  is  generally  characterized  by  acqui¬ 
sition,  development,  and  deployment  of 
capability  through  a  number  of  clearly 
defined  system  increments  that  stand  on 
their  own.  The  number,  size,  and  phasing 
of  the  increments  required  for  satisfaction 
of  the  total  scope  of  the  stated  user  require¬ 
ment  should  be  defined  by  the  program 
manager,  in  consultation  with  the  user.  An 
incremental  model  is  most  appropriate 
when  the  user  requirements  are  well 
understood  and  easily  defined,  but  assess¬ 
ment  of  other  considerations  (e.g.,  risks, 
funding,  schedule,  size  of  program,  or 
early  realization  of  benefits)  indicates  a 
phased  approach  is  more  prudent  or 
beneficial.  An  example  of  this  model  is 
pre-planned  product  improvement. 

Evolutionary  model.  This  model  is 
characterized  by  the  design,  development, 
and  deployment  of  a  preliminary  capabil¬ 
ity  using  current  technology  that  includes 
provisions  for  the  evolutionary  addition 
of  future  capabilities  as  requirements  are 
further  defined  and  technologies  mature. 
The  evolutionary  model  differs  from  the 
incremental  model  in  that  the  total  func¬ 
tional  capability  is  not  completely  defined 
at  inception,  but  evolves  as  the  system  is 
built.  This  model  offers  an  alternative  to 
the  traditional  model  for  those  programs 
not  requiring  a  leap  in  technology,  where 
the  design  process  includes  technology 
maturation,  and  where  a  program  can 
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make  use  of  an  interim  solution  with 
successive  upgrades. 

Advanced  concept  technology  demon¬ 
strations  (ACTDs)  and  evolutionary 
models  share  some  similarities  in  that  both 
involve  short  cycle  times  and  address  a 
requirement  for  state-of-the-art  technol¬ 
ogy.  ACTDs,  however,  are  oriented  to  the 
development  of  an  operational  concept 
and  do  not  necessarily  result  in  a  produc¬ 
tion  program.  Evolutionary  models  are 
oriented  toward  production  from  the 
beginning.  (Note:  The  Defense  Acquisi¬ 
tion  Deskbook  contains  several  excellent 
sources  of  additional  information  on  the 
evolutionary  model,  including  the  DSMC 
Guide  for  Evolutionary  Acquisition,  the 
Australian  Defence  Department  handbook, 
and  the  Global  Command  and  Control 
System  Lessons  Learned.) 

Other  program  models.  The  models 
described  above  may  be  tailored  to  support 
commercial  item  and  nondevelopmental 
item  acquisitions. 

Development  Models 

The  following  descriptions  of  the 
waterfall,  spiral,  and  spiral-to-circle 
models  are  extracted  from  The  Art  of  Sys¬ 
tems  Architecting  by  Rechtin  and  Maier 
(1997). 

Waterfall  model.  The  waterfall  model 
describes  a  sequence  of  largely  irrevers¬ 
ible  steps  especially  typical  of  hardware 
acquisition  and  production  plant  construc¬ 
tion.  Although  the  waterfall  method  is  less 
appropriate  for  software  development,  it 
is  sometimes  used  for  software-intensive 
systems. 

Spiral  model.  The  iterative  process  of 
software  development  is  better  represented 
by  a  spiral  expanding  through  four  quad¬ 
rants:  function,  form,  build  (code),  and 


test.  In  the  DoD  environment,  function 
equates  to  requirements  definition;  form 
equates  to  design;  build  equates  to  devel¬ 
opment;  and  test  equates  to  test  and  evalu¬ 
ation.  In  this  model  continually  expanding 
software  versions  are  based  on  learning 
from  earlier  development. 

The  spiral  model  is  attributed  to  Boehm 
(1988),  who  developed  and  applied  the 
model  to  large  government  software 
projects  while  working  for  TRW.  The 
spiral  model  creates  a  risk-driven 
approach  to  the  software  process,  rather 
than  primarily  a  document-driven  or  code- 
driven  process.  Each  cycle  of  the  spiral 
begins  with  the  identification  of  the 
objectives  of  the  portion  of  the  product 
being  elaborated  (performance,  function¬ 
ality,  ability  to  accommodate  change,  etc.); 
the  alternative  means  of  implementing  this 
portion  of  the  product  (design  A,  design 
B,  reuse,  buy,  etc.);  and  the  constraints 
imposed  on  the  application  of  the  alterna¬ 
tives  (cost,  schedule,  interfaces,  etc.).  The 
following  steps  evaluate  the  alternatives, 
and  identify  and  resolve  risks;  develop  and 
verify  the  next-level  of  product;  and  plan 
the  next  phases. 

Spiral-to-circle  model.  This  single¬ 
process  model  accommodates  the  impera¬ 
tives  of  both  the  hardware  and  software 
development  processes  based  on  the  fol¬ 
lowing  heuristic:  Complex  systems  will 
develop  and  evolve  within  an  overall 
architecture  much  more  rapidly  if  there  are 
stable  intermediate  forms  than  if  there  are 
not.  In  hardware  development,  the  model 
implies  scheduled  holds  at  the  end  of  each 
step  in  the  sequence  to  review  the  develop¬ 
ment  and  to  determine  that  the  integrity  of 
the  system  concept  has  not  been  violated 
(everything  necessary  has  been  done  and 
nothing  unnecessary  has  been  added).  In 
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software  development,  the  model  implies 
pausing  in  the  outward  spiral  from  time 
to  time  by  going  into  a  closed  circle  to 
create  a  stable  version. 

Because  the  spiral-to-circle  model  is  a 
single  model,  it  implies  that  the  interme¬ 
diate  form  is  not  only  stable,  but  could  also 
usefully  continue  as  a  product  indefinitely 
(even  as  an  acceptable  end  point  should 
budget  constraints  or  operational  needs  so 
dictate).  Meanwhile,  research,  develop¬ 
ment,  analysis,  prototyping  could  continue 
to  cycle  on  that  circle  until  the  decision  is 
made  to  expand  outward  to  new  functions 
and  forms. 

Software  product  line  model.  Soft¬ 
ware  product  lines  are  software  systems 
that  share  a  set  of  common  attributes  (e.g., 
functionality,  architecture,  design,  compo¬ 
nents/modules,  development/maintenance 
processes).  With  these  common  attributes 
as  a  foundation,  unique  systems  can  be 


built  to  satisfy  specific  customers’  require¬ 
ments.  The  product  line  model  was 
prototyped  by  the  Defense  Advanced  Re¬ 
search  Projects  Agency  (DARPA)  soft¬ 
ware  technology  for  adaptable,  reliable 
systems  (STARS)  program.  The  STARS 
pilots  successfully  demonstrated  the 
benefit  of  developing  a  common  archi¬ 
tecture  and  standards  within  a  software 
domain  (i.e.,  command  and  control)  and 
then  exploiting  that  common  base  to  sig¬ 
nificantly  reduce  the  design,  develop¬ 
ment,  and  testing  time  for  follow-on 
applications  in  that  domain.  More  infor¬ 
mation  on  the  STARS  project  is  avail¬ 
able  on  the  World  Wide  Web  at  http:// 
www.asset.com/stars/.  The  Defense 
Information  Infrastructure  Common 
Operating  Environment  (DII  COE)  is  a 
product  line  focused  on  the  infrastructure 
(vice  application)  level. 
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Appendix  B 


GPRA,  CLINGER-COHEN  ACT,  AND 
OMB  Implementing  Guidance 

Government  Performance 
and  Results  Act 

The  Government  Performance  and 
Results  Act  (GPRA)  of  1993  required 
agencies  to  submit  strategic  plans  to  the 
Office  of  Management  and  Budget  (OMB) 
by  September  30,  1997.  The  plans  were 
to  include: 

•  a  comprehensive  mission  statement  for 
major  functions  and  operations  of  the 
agency; 

•  general  and  outcome-related  goals; 

•  a  description  of  how  the  agency  will 
achieve  the  goals  and  the  operational 
processes  and  resources  required; 

•  a  description  of  how  the  goals  relate  to 
annual  performance  plan  goals; 

•  an  identification  of  key  factors  exter¬ 
nal  to,  and  beyond  the  control  of,  the 
agency  that  could  significantly  affect 
the  achievement  of  goals;  and 

•  a  description  of  program  evaluations 
the  agency  used  in  establishing  and  re¬ 
vising  general  goals,  with  a  schedule 
for  future  program  evaluations. 

The  DoD  Strategic  Plan  is  the  Quadren¬ 
nial  Defense  Review. 


Clinger-Cohen  Act 

The  purpose  of  the  Clinger-Cohen  Act 
of  1996  is  to  improve  the  productivity, 
efficiency,  and  effectiveness  of  federal 
programs  through  the  improved  acquisi¬ 
tion,  use,  and  disposal  of  information  tech¬ 
nology  (IT)  resources.  Among  other 
provisions,  the  law  requires  executive 
agencies  to  design  and  implement  a 
process  for  maximizing  the  value  and 
assessing  and  managing  the  risks  of  IT  ac¬ 
quisitions.  The  Clinger-Cohen  Act  also 
streamlines  the  IT  acquisition  process  by 
encouraging  the  adoption  of  smaller, 
modular  IT  acquisition  projects.  With  cer¬ 
tain  exceptions,  the  Clinger-Cohen  Act  is 
generally  applicable  to  National  Security 
Systems. 

OMB  Capital  Punning  Guidance 

The  OMB  Capital  Planning  Guide 
(Supplement  to  Circular  A-ll,  Part  3) 
integrates  various  asset  management 
initiatives  (GPRA,  Clinger-Cohen  Act, 
etc.)  into  a  single,  integrated  capital  plan¬ 
ning  process  to  ensure  that  capital  assets 
contribute  to  the  achievement  of  agency 
strategic  goals  and  objectives.  The  defi¬ 
nition  of  capital  assets  includes  IT  hard¬ 
ware,  software,  and  modifications;  and  DoD 
weapons  systems.  The  four  phases  of  the 
capital  planning  process  are  planning, 
budgeting,  procurement,  and  management- 
in-use. 

In  the  planning  phase,  the  intent  is  for 
strategic  plans,  annual  performance  plans, 
and  plans  for  capital  assets  to  flow  from 
the  same  process  for  identifying  a  baseline 
of  current  performance  and  the  gap 
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between  current  and  planned  performance; 
functional  requirements  for  bridging  this 
gap;  alternatives  for  meeting  these  func¬ 
tional  requirements;  the  best  capital  asset 
solution  if  one  is  needed;  and  a  summary 
of  proposed  funding,  procurement,  and 
management  of  each  capital  asset  within 
the  agency’s  portfolio  of  assets  in  an 
agency  capital  plan.  The  acquisition  strat¬ 
egy  and  risks  are  part  of  the  information 
provided  when  seeking  approval  of  a 
project. 

Although  budgeting  begins  in  the  plan¬ 
ning  phase,  the  formal  start  of  the  budget¬ 
ing  phase  is  the  agency’s  request  to  OMB 
for  asset  acquisition.  Agency  budget  sub¬ 
missions  should  be  consistent  with  the 
“Principles  of  Budgeting  for  Capital  Asset 
Acquisitions,”  which  was  published  with 
the  fiscal  year  1998  budget.  DoD  guid¬ 
ance  for  implementing  these  principles  is 
documented  in  the  May  1,  1997,  Office 
of  the  Secretary  of  Defense  memorandum, 
“Requirements  for  Compliance  with 
Reform  Legislation  for  Information  Tech¬ 
nology  (IT)  Acquisitions  (Including 
National  Security  Systems).”  The  budget¬ 
ing  phase  ends  when  Congress  appropri¬ 
ates  funds  for  the  acquisition  and  OMB 
apportions  the  funds  to  the  agency. 

OMB’s  procurement  phase  is  essen¬ 
tially  equivalent  to  the  DoD  acquisition 
process.  Key  steps  in  this  phase  are  to: 

•  validate  the  planning  decision; 

•  manage  the  procurement  risk; 

•  consider  tools  (modular  contracting, 

two-phased  acquisition,  competitive 

prototyping); 


•  select  contract  type  and  pricing 
mechanism; 

•  issue  the  solicitation; 

•  conduct  proposal  evaluation  and 
negotiation; 

•  award  the  contract; 

•  manage  the  contract; 

•  conduct  acquisition  analysis;  and 

•  conclude  with  acceptance  (testing). 

The  management-in-use  phase  includes 
the  steps  an  agency  should  take  to  man¬ 
age  and  evaluate  the  continued  viability 
of  an  acquired  capital  asset  as  part  of  the 
agency  portfolio.  The  steps  in  this  phase 
include: 

•  operational  analysis  (which  can  be  used 
to  minimize  the  cost  of  asset  owner¬ 
ship  while  simultaneously  improving 
the  function  the  asset  performs); 

•  execution  of  the  operation  and  main¬ 
tenance  plan; 

•  post-implementation  review  (to 
evaluate  the  overall  effectiveness  of 
the  agency’s  capital  planning  and 
acquisition  process);  and 

•  execution  of  the  asset  disposal  plan. 
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Appendix  C 


Other  Relevant  Guidance 
and  Best  Practices 


Architecture  Synchronization 

DoD  has  adopted  the  concept  of  mul¬ 
tiple,  linked  architectures  to  describe  the 
operational,  system,  and  technical  views 
of  information  technology-based  systems. 
Comprehensive  DoD-wide  architectural 
guidance  is  described  in  the  Command, 
Control,  Communications,  Computers,  In¬ 
telligence,  Surveillance,  and  Reconnais¬ 
sance  (C4ISR)  Architecture  Framework 
Version  2.0,  which  was  approved  for 
implementation  in  February  1998.  Version 
2.0  of  the  C4ISR  Architecture  Framework 
is  available  at  http://www.cisa.osd.mil. 

The  following  architecture  descriptions 
are  from  various  DoD  architecture  Web 
pages. 

Operational  architecture.  An  opera¬ 
tional  architecture  is  a  set  of  elements  con¬ 
sisting  of  information  exchange  require¬ 
ments,  mission  area  interactions,  tasks, 
interoperability  tables,  logical  connectiv¬ 
ity,  and  a  description  of  the  environment 
where  the  information  system  is  to  be  op¬ 
erated.  The  operational  architecture  is  tied 
to  both  the  systems  and  technical  archi¬ 
tectures  and  provides  a  disciplined  ap¬ 
proach  or  methodology  to  review  baseline 
requirements,  assess  doctrinal  impacts,  ex¬ 
amine  and  assess  alternatives  through  ex¬ 
cursions  (functional  or  process  improve¬ 
ments;  and  doctrine,  training,  leader  de¬ 
velopment,  organization,  materiel,  and 
soldiers  [DTLOMS]  requirements).  An 
operational  architecture: 


•  identifies  the  mission  objective; 

•  identifies  information  exchange 
requirements; 

•  identifies  logical  connectivities;  and 

•  identifies  operational  elements. 

Systems  architecture.  A  systems  archi¬ 
tecture  view  is  a  description,  including 
graphics,  of  systems  and  interconnections 
providing  for  or  supporting  warfighting 
functions.  It  is  a  representation  that 
associates  physical  systems  and  their 
performance  attributes  to  the  operational 
architecture  and  is  built  following  the 
standards  in  the  technical  architecture.  A 
systems  architecture: 

•  maps  information  exchange  require¬ 
ments; 

•  defines  connections  between  compo¬ 
nents; 

•  defines  capacity; 

•  defines  performance;  and 

•  defines  constraints. 

Technical  architecture.  A  technical 
architecture  is  a  minimal  set  of  rules 
governing  the  arrangement,  interaction, 
and  interdependence  of  the  parts  or 
elements  that  together  may  be  used  to  form 
a  system,  and  whose  purpose  is  to  ensure 
that  a  conformant  system  satisfies  a 
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specified  set  of  requirements.  A  technical 
architecture  identifies  the  services,  inter¬ 
faces,  standards,  and  their  relationships. 
A  technical  architecture: 

•  defines  systems  rules; 

•  establishes  standards  for  interopera¬ 
bility;  and 

•  applies  technology  references  that  in¬ 
fluence  architecture  decisions. 

(Note:  The  Joint  Technical  Architecture 
is  mandatory  for  all  C4I  systems.) 

Flexible  OT&E  Strategies 

OT&E  strategy  for  software-inten¬ 
sive  systems.  Since  1992,  the  Army  has 
used  a  flexible  operational  test  and  evalu¬ 
ation  (OT&E)  strategy  to  support  faster 
fielding  of  software-intensive  systems  that 
have  been  divided  into  blocks  of  function¬ 
ality  (increments).  The  strategy  allows 
partial  fielding  of  software-intensive 
systems,  once  successful  OT&E  of  a 
representative  sample  has  been  accom¬ 
plished.  A  representative  sample  is  the 
portion  of  the  software  to  be  developed 
that  demonstrates  the  ability  of  the  hard¬ 
ware,  commercial  off-the-shelf  (COTS) 
software,  and  communications  network  to 
support  the  total  system  requirements.  The 
strategy  is  applicable  both  to  weapon  sys¬ 
tems  with  extensive  embedded  software 
and  information  systems.  The  approach 
supports  multiple  software  development 
models,  enhances  the  program  manager’s 
acquisition  strategy,  and  reduces  the  risk 
to  the  warfighter  and  the  decision  maker. 

OT&E  guidelines  for  software-inten¬ 
sive  system  increments.  In  October  1996, 


the  Office  of  the  Director  of  Operational 
Test  and  Evaluation  (DOT&E)  published 
guidelines  intended  to  streamline  the 
OT&E  process  and  to  achieve  “affordable 
confidence”  for  the  development  and  pro¬ 
curement  of  software-intensive  systems. 
The  guidelines  apply  to  increments  of  soft¬ 
ware-intensive  systems  acquired  subse¬ 
quent  to  deployment  of  the  “core  block,” 
which  undergoes  full  operational  testing. 
For  insignificant  to  moderate  risk  incre¬ 
ments,  these  guidelines  streamline  the 
OT&E  process  by  reducing  the  degree  of 
testing.  The  guidelines  are  applicable  to 
both  the  incremental  and  evolutionary 
models. 

OT&E  test  windows.  One  of  the  issues 
that  the  1989  Army  Science  Board  Sum¬ 
mer  Study  on  the  Army  Tactical  Command 
and  Control  System  (ATCCS)  addressed 
was  how  to  synchronize  changes  to  the 
component  ATCCS  programs  after  the 
core  systems  were  deployed.  The  recom¬ 
mended  solution  was  to  establish  opera¬ 
tional  test  “windows”  that  would  be  sched¬ 
uled  once  or  twice  a  year  so  that  develop¬ 
ers  could  ensure  continued  interoperability 
and  minimize  operational  risk  before 
deploying  follow-on  increments.  The 
Army  Program  Executive  Office  for 
Command,  Control,  and  Communications 
Systems  has  recently  proposed  a  similar 
process  to  synchronize  the  development, 
testing,  and  fielding  cycles  of  the  Army 
Battlefield  Command  System  component 
systems. 

Blocked  ORDs 

Users  occasionally  write  operational 
requirements  documents  (ORDs)  that  di¬ 
vide  the  requirements  into  “blocks”  for 
incremental  design,  development,  and 
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deployment,  but  there  is  currently  no 
explicit  guidance  on  how  to  “block” 
ORDs.  Several  years  ago,  the  automated 
information  systems  community  proposed 
an  approach  by  which  the  user  and  pro¬ 
gram  manager  would  work  together  to 
sectionalize  the  ORDs,  relying  on  the 
user’s  operational  (functional)  knowledge 
and  the  program  manager’s  technical 
knowledge.  The  premise  was  that  a  viable 
acquisition  strategy  requires  an  ORD  that 
can  be  implemented  both  technically  and 
operationally.  If  not  done  collaboratively, 
the  user  may  propose  a  solution  that  is  not 
technically  viable;  conversely,  the  pro¬ 
gram  manager  may  propose  a  technical 
solution  that  cannot  be  implemented 
operationally.  The  proposal  also  included 
suggestions  for  defining  system  incre¬ 
ments  in  terms  of  functionality,  user  class 
or  echelon,  or  operational  mode. 


Global  Command  and  Control  System 

The  Global  Command  and  Control  Sys¬ 
tem  (GCCS)  has  implemented  an  evolu¬ 
tionary  acquisition  strategy  that  integrates 
the  requirements  and  acquisition  processes 
to  ensure  the  early,  concurrent  consider¬ 
ation  of  operational,  technical,  procedural, 
test,  support,  and  fiscal  issues  within  the 
GCCS  stakeholder  community.  The 
Defense  Acquisition  Deskbook  has  infor¬ 
mation  on  the  GCCS  evolutionary  acqui¬ 
sition  process.  Additional  information  is 
contained  in  an  Institute  for  Defense 
Analysis  paper  that  describes  how  the  in¬ 
tegrated  product  team  process  and  DoD 
5000  series  policy  were  tailored  to  accom¬ 
modate  the  evolutionary  nature  of  GCCS. 
The  IDA  paper  is  available  on  the  Web  at: 
http://www.ida.org/DIVISION/sfrd/ 
IDAJPapersJDocuments.html. 
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"SUBCONTRACTING" 
AS  A  SOLUTION, 
NOT  A  PROBLEM, 
IN  OUTSOURCING 

William  N.  Washington 


As  outsourcing  has  come  into  vogue  for  both  commercial  and  government 
downsizing  initiatives,  the  success  or  failure  of  the  contracting  efforts  has 
increasingly  become  dependent  on  the  effectiveness  of  the  related 
subcontracting.  With  that  extensive  subcontracting  has  come  loss  of  control 
and  often  disappointing  cost  savings.  The  response  of  some  companies  has 
been  to  select  their  own  subcontractors — which  has  resulted  in  cost  savings, 
but  also  has  created  the  necessity  for  increased  contract  monitoring.  Whether 
or  not  one  uses  this  new  approach,  several  measures  can  be  included  in  the 
contract  to  improve  the  likelihood  that  the  outsourcing  will  be  successful  in 
terms  of  cost  savings  and  task  performance. 


Over  the  past  several  years  busi¬ 
nesses  have  adopted  a  new  man¬ 
agement  philosophy  which  asserts 
that  the  organization  does  not  grow  and 
prosper  through  acquisitions,  but  rather 
through  partnering  and  networking.  Part 
of  this  new  mindset  entails  that  the  orga¬ 
nization  no  longer  needs  direct  line  con¬ 
trol  over  all  of  its  components.  Rather, 
components  that  are  not  part  of  the  “core 
functionality”  of  the  organization  might 
be  better  performed  by  experts  from  those 
areas.  This  would  reduce  the  overhead 
expenses  of  the  organization,  and  improve 


the  quality  of  the  work  product.  This  trend 
is  similar  to  the  trend  in  hardware  manu¬ 
facturing,  where  manufacturers  no  longer 
need  to  produce  all  the  components  of 
their  products  inhouse.  Instead,  they 
competitively  procure  components  from 
outside  the  company  to  use  in  the 
manufacturing  process. 

As  outsourcing  has  become  more 
accepted,  and  more  companies  outsource 
whole  functions,  especially  in  the  auto¬ 
matic  data  processing  ( ADP)  area,  subcon¬ 
tracting  and  how  it  is  handled  could  have 
a  significant  impact  on  the  success  or 
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failure  of  the  outsourcing  effort.  This 
concern  came  to  light  in  a  Deloitte  and 
Touche  study  that  included  a  survey  of 
1 ,500  chief  information  officers  (CIOs)  in 
the  United  States  and  Canada,  which 
indicated  that  only  3 1  percent  believed  that 
their  outsourcings  generated  significant 
cost  savings,  with  69  percent  being 
disappointed  in  their  outsourcing  results 
(“Uneasy  Pieces,”  1997).  This  survey 
made  two  things  apparent. 

First,  these  executives  believed  that 
they  would  achieve  savings  through 
economies  of  scale  or  superior  contractor 
resources.  But  these  expectations  did  not 
materialize,  because  the  fixed-price  con¬ 
tracts  they  entered  into  did  not  subse¬ 
quently  pass  along  the  hardware,  software, 
or  personnel  savings  over  time.  These 
experiences  were  also  supported  by  Lacity 
and  Hirschheim  (1993),  Lacity,  Willcocks, 
and  Fitzgerald  (1996),  and  Scheier  (1997), 
who  found  that  commercial  contracts  deal¬ 
ing  with  outsourcings  have  experienced 
problems  with  long-term  contracts  simi¬ 
lar  to  those  previously  mentioned.  As  such, 
the  current  trend  has  been  to  look  at  shorter 
time  spans,  so  that  changes  in  scope  and 
productivity  improvements  can  be 
reflected  in  the  contract  agreement;  or,  to 
frame  the  contract  such  that  it  is  renegoti¬ 
ated  at  periodic  intervals  to  adjust  it  to 
current  market  prices  or  changes  in 
requirements. 

Second,  the  executives  also  complained 
that  vendors  were  not  up  front  about  the 
amount  of  subcontracting  that  would  be 
used  for  the  execution  of  their  contracts. 
This  became  a  problem  when  the  subcon¬ 
tractor  was  unfamiliar  with  the  contract 
-provisions  or  customer  expectations,  and 
did  not  deliver  the  required  services  in  the 
expected  way.  This  concern  was  also 


voiced  in  an  Info  World  article  (“Manag¬ 
ing  Your  Outsourcing,”  1996),  which  de¬ 
scribed  how  many  firms  that  had 
outsourced  their  information  technology 
functions  were  starting  to  reduce  the 
scope,  or  cancel  parts  of  those  efforts, 
because  of  lack  of  control  over  the  vendors 
or  subcontractors. 

These  results  were  similar  to  an  earlier 
Gartner  Group  survey  of  180  clients 
(1995),  which  found  that  only  about  37 
percent  of  information  technology 
outsourcings  were  viewed  as  being  suc¬ 
cessful,  either  through  improved  perfor¬ 
mance  (21  percent),  or  cost  savings  (16 
percent);  while  the  remainder  of  the 
respondents  indicated  either  a  mixed  or 
too-eariy-to-tell  response.  Recent  Gartner 
Group  surveys  have  continued  to  show 
that  gains  from  outsourcing  have  consis¬ 
tently  fallen  short  of  expectations  by  CIO’s 
(“Outsourcing  to  the  Rescue,”  1997). 
These  surveys  blamed  the  contracting  pro¬ 
cess  for  not  defining  key  issues  and  an¬ 
ticipated  expectations.  In  the  article, 
Gartner  vice  president  Mike  Vargo  said 
customers  also  do  not  realize  that  an 
outsourcing  relationship  takes  more  time 
and  effort  than  they  anticipated. 

Subcontracting  as  a  Solution, 

Not  a  Problem 


The  above  problems  reflect  what  can 
happen  when  little  thought  is  given  to  the 
outsourced  function.  In  a  perfect  world, 
of  course,  it  would  be  much  easier  to  allow 
a  prime  contractor  to  manage  the  whole 
outsourced  function,  smoothing  over 
difficulties  and  integrating  the  sub¬ 
contractor’s  performance.  However,  the 
above  study  indicates  that  the  prime 
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contractor  may  not  always  be  good  at 
performing  those  functions,  or  may  not 
choose  the  least  expensive  approach. 

The  government  might  address  these 
concerns  in  one  of  two  ways.  First,  it  can 
undertake  its  own  selection  of  subcontrac¬ 
tors,  and  subsequently  monitor  their  per¬ 
formance,  by  contracting  separately  for 
each  “subcontractor”  function.  Thus,  it  can 
convert  what  normally  would  be  subcon¬ 
tractor  functions  (which  cannot  be  moni¬ 
tored  under  the  “privity  of  contract”  prin¬ 
ciple)  into  regular  contracted  functions, 
which  can  be  monitored  and  directed. 
Second,  it  can  place  detailed  monitoring 
measures  and  baselining  provisions  in  the 
contract. 

Selecting  your  own  subcontractors  as 
a  way  to  save  additional  money  on 
outsourcing  has  recently  become  a  popu¬ 
lar  avenue  for  those  companies  willing  to 
take  on  the  responsibility.  This  process  is 
similar  to  becoming  your  own  general 
contractor  in  building  a  house,  where  you 
interview  and  select  the  different  trade 
people  who  will  perform  the  various 
construction  tasks. 

Likewise,  in  information  technology 
endeavors,  multiple  vendors  are  selected 
according  to  their  areas  of  expertise.  This 
was  recently  done  by  Halliburton  Com¬ 
pany,  which  found  that  specialized  infor¬ 
mation  technology  vendors  could  provide 
optimal  services  for  as  much  as  10  to  15 
percent  less  than  what  a  prime  contractor 
would  charge  (“Outsourcing  Megadeals,” 
1995).  The  company  also  reported  that  by 
breaking  the  outsourcing  into  pieces,  it 
could  see  the  value  better  by  getting  a 
clearer  picture  of  where  the  vendor  was 
making  its  investments  and  profits.  Other 
companies  that  have  followed  this  strat¬ 
egy  are  Aetna,  Eastman  Kodak,  DuPont, 
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Zale’s,  and  J.  P.  Morgan;  they  all  sought 
better  service  and  more  control  over  their 
information  technology  (“The  New 
Outsourcing,”  1996).  Part  of  this  trend  of 
breaking  out 
functions  within 
an  outsourced 
area  originates 
from  the  recog¬ 
nition  that  a 
single  contractor 
is  usually  not 
able  to  perform 
all  the  functions 
required,  and,  in 
turn,  would  have 
to  subcontract 

some  functions  that  were  outside  of  its 
capability.  An  additional  benefit  of  select¬ 
ing  your  own  subcontractor  is  that  it 
allows  for  greater  control  over  what  is 
outsourced  and  what  remains  in  house. 

With  the  prospect  of  managing  several 
subcontractors,  some  thought  should  be 
given  as  to  how  they  will  work  together 
in  functioning  and  dealing  with  one 
another;  especially  since  some  areas  of 
responsibility  will  likely  overlap.  J.  P. 
Morgan  (“The  New  Outsourcing,”  1996; 
and  Bell  Atlantic,  1997),  in  its  outsourcing 
effort,  specified  a  risk-reward  contracting 
procedure  that  would  provide  positive  and 
negative  incentives  for  cooperation 
between  the  subcontractors.  In  this  reward 
contract,  savings  achieved  through  better 
procedures  and  purchases  would  be  put 
into  a  contingency  pool,  which  would  be 
shared  between  the  company  and  the  sub¬ 
contractors.  Likewise,  if  the  subcontrac¬ 
tors  did  not  perform  in  accordance  with 
the  specified  performance  measurements, 
they  would  be  penalized  by  some 
predetermined  amount. 
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It  should  be  said,  though,  that  the 
selection  and  monitoring  of  subcontrac¬ 
tors  is  a  two-edged  sword.  While  it  affords 
the  possibility  of  additional  outsourcing 
savings,  it  may  not  come  free  either  in 
terms  of  cost  or  time  required  to  manage 
the  effort.  It  could  cost  between  5  to  7  per¬ 
cent  of  the  value  of  the  contract  to  man¬ 
age  and  oversee  the  subcontractors.  That 
would  cover  renegotiating  the  contract 
agreements,  resolving  disputes,  and  track¬ 
ing  the  contractor’s  performance  (Scheier, 
1996).  These  costs  would  vary  depending 
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cost.  It  should  be  pointed  out,  however, 
that  these  costs  might  be  mitigated  con¬ 
siderably  if  sufficient  effort  is  spent  on 
carefully  defining  in  the  contract  how 
problems  are  to  be  resolved  and  how  un¬ 
expected  changes  in  requirements  are  to 
be  addressed. 

Another  concern  that  should  be  consid¬ 
ered  in  the  contracting  process  is  the 
degree  of  specificity  in  what  is  outsourced, 
and  what  specifically  the  contractor  is  sup¬ 
posed  to  do.  This  is  a  fine  line,  for  if  the 
service  levels  are  too  tightly  defined,  the 
government  could  end  up  paying  high  fees 
for  incremental  projects  outside  the 
defined  scope  of  the  contract.  For  instance, 
companies  have  reported  paying  as  much 
as  70  percent  more  than  the  original 
contract  value  for  tasks  outside  of  the 
defined  scope  of  the  contract  (Lacity  and 


Hirschhiem,  1993).  Thus,  there  will  be  a 
tradeoff  for  the  government,  to  make  the 
contracts  as  flexible  as  possible  to  cover  a 
broad  range  of  needs  and  changing 
requirements,  without  overburdening 
them  with  too  much  contract  oversight. 
Lacity  and  Hirschhiem  further  point  out 
that  outsourcing  does  not  seem  to  work 
well  in  the  following  areas: 

•  where  a  specific  or  unique  knowledge 
of  the  business  is  required; 

•  where  all  services  are  custom;  or 

•  where  the  employee  culture  is  too 
fragmented  or  hostile  for  the 
reorganization  to  come  back  together. 

An  additional  consideration  would  be 
how  the  contract  should  be  structured.  For 
instance,  the  offeror’s  proposal  should 
delineate  what  will  happen  to  all  of  the 
existing  assets  under  consideration:  Which 
ones  will  the  contractor  assume  responsi¬ 
bility  for,  which  ones  will  remain  with  the 
government,  and  which  if  any  will  go  to 
third  parties?  In  addition,  one  should  also 
consider  if  there  are  any  intellectual  prop¬ 
erty  issues,  such  as  software  licenses  (i.e., 
whether  existing  software  can  be  trans¬ 
ferred  to  the  outsourcer),  and  ownership 
of  self-developed  software. 

Finally,  a  significant  consideration  to 
improve  one’s  chances  of  having  a  suc¬ 
cessful  outsourcing  effort  concerns  the  use 
of  detailed  monitoring  measures  and 
baselining  provisions  that  should  be 
included  in  the  contract.  For  instance, 
there  are  a  number  of  measures  that  one 
can  include  in  the  contract  to  help  deter¬ 
mine  if  the  contractor  is  meeting  the  goals 
and  costs  projected  for  the  outsourcing 
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(Mylott,  1995;  Rubin,  1997).  These  mea¬ 
sures  can  be  grouped  together  under  the 
headings  of  performance  criteria  and 
comparability  measurements. 

Performance  Criteria 

These  measurements  are  those  that  can 
be  used  to  emphasize  areas  that  are  con¬ 
sidered  critical,  or  can  aid  in  the  customer 
satisfaction  process,  by  informing  the  con¬ 
tractor  what  specific  expectations  exist  for 
the  effort.  In  addition,  these  measures 
should  link  specific  operations  to  strate¬ 
gic  goals.  For  instance,  many  performance 
measurements  are  still  tied  to  the  old 
concepts  of  standard  accounting  that  were 
developed  back  in  the  1920s;  those  mea¬ 
surements,  however,  no  longer  represent 
the  current  work  environment  (Lynch  and 
Cross,  1991;  Drucker,  1988).  This  prob¬ 
lem  has  also  been  recognized  by  many 
accountants,  for  in  a  survey  at  a  meet¬ 
ing  of  the  National  Association  of  Ac¬ 
countants  and  Computer  Aided  Manu¬ 
facturing-International,  60  percent  of 
the  financial  officers  expressed  dissat¬ 
isfaction  with  their  current  performance 
measures  (Howell,  Brown,  Soucy  and 
Seed,  1987). 

Performance  measures  that  could  be 
problematic  are; 

•  The  purchase  price,  which  may  not 
reflect  quality  and  performance  of  the 
item; 

•  Machine  utilization,  which  is  subject 
to  managers  overrunning  the  machine 
to  maximize  utilization,  which  may  not 
be  warranted;  and 


and  not  activities,  thus  overlooking 
common  activities. 

Performance  measures  to  consider  are: 

•  Response  time.  Specify  an  average  or 
specific  response  time  for  maintenance 
on  critical  equipment  or  software. 

•  System  availability.  Specify  that  par¬ 
ticular  hardware  or  software  is 
functional  on  a  daily,  by  shift,  or  by 
application  basis. 

•  Downtime.  Specify  that  particular 
hardware  or  software  be  down  less  than 
a  particular  amount  of  time,  or  require 
a  particular  mean-time-between- 
failure. 

•  Turnaround  time  or  schedule  of  per¬ 
formance.  Specify  either  a  specific 
turnaround  time  on  repairs,  or  a  par¬ 
ticular  schedule  of  performance  for 
equipment. 

•  Performance  reports.  Specify  general 
performance  criteria  that  are  considered 
important  to  the  outsourcing  effort. 

•  Penalties  for  nonperformance.  Pen¬ 
alties  might  also  be  used  on  some  of 
the  availability  factors,  to  add  em¬ 
phasis  for  meeting  the  specific 
performance  requirements. 

•  Satisfactory  performance  statement. 

State  the  organization’s  expectations  of 
the  vendor.  These  need  to  be  clearly 
defined  and  discussed  with  the  vendor. 


Cost  center  reporting,  which  is  sub¬ 
ject  to  managers  focusing  on  centers 
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specifying  what  mission  critical 
projects  or  systems  are  handled  only 
by  the  primary  vendor. 

Comparability  Measurements 

For  comparison,  reports  can  be  used  to 
determine  if  the  contract  is  relevant  to 
similar  costs  for  these  services  by  other 
providers. 

•  Operation’s  cost  measures.  Specify 
that  the  contractor  report  cost  in  terms 
of  CPU  hours,  storage  costs,  total  cost 
per  hour,  fixed  costs,  or  variable  costs. 

•  Communication’s  cost  measures. 

Specify  that  the  contractor  report  cost 
per  hour,  by  distance,  per  line,  or  per 
switch. 

•  Service’s  cost  measures.  Specify  that 
the  contractor  report  costs  per  person, 
or  per  application. 

•  Value-based  pricing  and  bench¬ 
marking.  Specify  that  the  contractor 
periodically  adjust  the  contract  price  to 
the  “market  price.”  An  alternative  to 
this  would  be  to  negotiate  rates 
annually. 

These  measures  should  be  reported  on 
a  monthly  basis,  and  consist  of  a  mix  of 
both  performance  and  comparability 
measures,  which  would  be  used  to  deter¬ 
mine  the  monthly  payment  for  the  con¬ 
tractors.  On  the  basis  of  their  performance, 
the  contractor  may  receive  either  an 
incentive  fee  for  exceeding  certain  perfor¬ 
mance  perimeter  bands,  or  a  penalty  for 


falling  below  those  bands.  Scheier  (1997) 
also  suggests  that  cost  measures  should 
be  broken  out  for  specific  items,  rather 
than  bundling  large  areas  together,  to  make 
it  easier  to  pinpoint  which  prices  should 
be  renegotiated. 

Discussion _ _____ 

In  general,  outsourcing  has  become  a 
very  popular  vehicle  in  the  commercial 
sector,  with  more  and  more  companies  and 
now  government  entities  obtaining  ser¬ 
vices  in  this  way  (Washington,  1997).  To 
maximize  the  possible  savings  and  achieve 
the  desired  performance  improvement, 
considerable  forethought  is  necessary  in 
stmcturing  the  contract,  in  monitoring  the 
contractor’s  performance,  and  in  the 
administration  and  oversight  of  the  con¬ 
tract.  One  of  the  ways  that  additional 
savings  could  be  achieved  in  the  out¬ 
sourcing  area  would  be  through  the 
selection  and  monitoring  of  the  subcon¬ 
tractors  for  specific  areas  of  expertise. 
Care  needs  to  be  taken  here,  however,  for 
there  are  both  additional  costs  and  time 
requirements  associated  with  the  process. 

To  mitigate  some  of  the  potential  risks 
with  outsourcings  due  to  problems  with 
the  contracting  process,  a  number  of  per¬ 
formance  measures  should  be  included  in 
the  contract  to  aid  in  meeting  its  goals  for 
both  performance  and  cost.  These  mea¬ 
sures  would  then  be  used  in  the  contract 
administration  process  to  make  sure  that 
the  contract  is  on  track,  and  also,  perhaps, 
to  control  contractor  payments. 
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TUTORIAL 


REENGINEERING  THE 
ACQUISITION  PROCESS: 

A  QUANTITATIVE  EXAMPLE 
OF  ACQUISITION  REFORM 
WORKING  FOR  THE 
AIR  FORCE'S  LAUNCH  PROGRAMS 
SYSTEM  PROGRAM  OFFICE 


Robert  Graham  and  Capt  irk  Hoffman,  USAF 


The  objective  of  the  Air  Force’s  Launch  Programs  System  Program  Office 
(SPO)  was  to  develop  and  improve  the  acquisition  process.  Realizing  that  the 
cycle  time  for  contract  proposals  was  an  area  that  needed  reform,  the  Launch 
Programs  SPO  set  out  to  reengineer  the  process.  By  developing  a  contractor 
and  government  integrated  product  team  that  worked  together  to  define  a 
new  streamlined  approach  for  making  changes  to  existing  contracts,  the 
Launch  Programs  SPO  has  quantitatively  demonstrated  an  average  63  percent 
cycle  time  reduction. 


The  mission  of  the  Air  Force’s  Launch 
Programs  System  Program  Office 
(SPO)  at  Los  Angeles  Air  Force 
Base,  CA,  which  oversees  the  Titan,  Delta, 
and  Atlas  launch  vehicles,  and  the  Centaur 


and  Inertial  Upper  Stage  boosters,  is  to 
acquire  and  sustain  a  reliable,  affordable 
national  space  launch  capability.  Launch 
Programs  is  facing  the  challenges  com¬ 
mon  to  the  Department  of  Defense  (DoD): 


The  views  expressed  here  are  those  of  the  authors  and  do  not  necessarily  reflect  those  of  the 
Air  Force  or  Launch  Programs  SPO. 
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downsizing,  turnover,  and  competition.  To 
meet  the  goals  outlined  in  the  National 
Performance  Review  and  Air  Force  Light¬ 
ning  Bolts,  the  Launch  Programs  system 


program  office  at  the  Air  Force’s  Space 
and  Missile  Systems  Center  launched  its 
own  aggressive  business  process  reengi¬ 
neering  initia- 


"In  the  past, 
making  modifica¬ 
tions  to  contracts 
has  been  a  long, 
tedious  process../ 


tive  to  design 
and  implement 
an  improved 
and  streamlined 
contract  change 
process  (CCP). 
The  specific 


goals  of  the  reengineering  initiative  were 
to  streamline  the  contract  change  process; 
reduce  process  cycle  time  by  at  least  50 
percent;  and  implement  a  comprehensive 
training  program.  To  achieve  those  goals, 
the  organization  emphasized  teamwork, 
accountability,  project  management,  and 


empowerment. 

In  the  past,  making  modifications  to 
contracts  has  been  a  long,  tedious  process; 
it  is  a  problem  that  pervades  every  part  of 
the  government  procurement  system.  The 
traditional  process  by  which  one  puts  an 
engineering  change  proposal  (ECP)  on 
contract  has  six  broad  areas,  in  which 
decisions,  roles  and  responsibilities,  and 
processes  are  conducted  in  a  bureaucratic 
environment.  First,  the  project  officer 
develops  a  requirement  without  contrac¬ 
tor  input  (Category  1:  Requirement 
Development).  The  contracting  officer 
develops  and  issues  a  request  for  proposal 
(RFP)  in  a  vacuum,  without  contractor 
participation  (Category  2:  RFP  Develop¬ 
ment).  It  is  then  the  contractor’s  responsi¬ 
bility  to  understand  and  interpret  the 
government’s  requirement  and  propose  a 
meaningful  solution  that  is  acceptable  to 


the  government.  The  contractor  accom¬ 
plishes  this  without  government  assistance 
or  insight  (Category  3:  Proposal  Develop¬ 
ment).  The  result  is  numerous  revised 
proposals  and  technical  meetings  to 
understand  the  government’s  requirements. 

During  the  proposal  review,  the  require¬ 
ment  is  eventually  defined  and  the 
contractor  gains  full  knowledge  of  the 
government’s  requirement  (Category  4: 
Proposal  Review).  Negotiations  are 
usually  adversarial  (Category  5:  Negotia¬ 
tions).  Finally  comes  the  time-consuming 
process  of  awarding  the  contract  modifi¬ 
cation,  with  numerous  burdensome 
regulations  (Category  6:  Contract  Award). 
Everyone  has  agreed  that  this  process  is 
broken,  but  for  Launch  Programs,  it  was 
not  until  the  introduction  of  the  reengi¬ 
neered  contract  change  process  that  the 
traditional  process  was  eliminated  and  an 
integrated  product  team  (IPT)  developed 
a  streamlined  method  for  accomplishing 
a  contract  modification. 

Several  years  ago  the  Delta  II  Launch 
Vehicle  IPT  assembled  a  team  that  pro¬ 
posed  the  innovative  process  now  used  by 
Launch  Programs.  The  process  basically 
“front-loads”  a  large  portion  of  the  work 
that  used  to  be  completed  after  the  con¬ 
tractor  submitted  its  proposal.  The  new 
process  forces  the  government  to  work 
with  the  contractor  as  a  team  to  develop 
the  requirement  for  a  contract  change.  The 
teamwork  continues  during  the  request  for 
proposal  (RFP)  and  proposal  development 
process,  and  the  team  actually  reaches 
consensus  on  the  hours  and  materials 
required  to  complete  the  project  before  the 
proposal  is  submitted  to  the  government. 
Thus,  once  the  proposal  is  actually 
submitted  to  the  government,  it  is  known 
exactly  what  it  will  contain,  and  ultimately 
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the  government  dramatically  reduces  the 
turnaround  time  for  putting  an  ECP  on 
contract. 

The  Reengiheered  Contract 
Chance  Process _ _ 

The  contract  change  process  that 
reduced  cycle  time  for  the  Launch  Pro¬ 
grams  system  program  office  is  organized 
into  six  stages:  need  validation;  solution 
definition;  proposal  request,  preparation, 
and  review;  proposal  disposition;  contract 
modification  completion;  and  contract 
modification  signature  and  distribution 
(Figure  1).  The  purpose  and  description 
of  each  stage  is  provided  below,  as  well 
as  the  improvements  gained  through  the 
reengineering  effort. 

Stage  1:  Need  Validation 

The  purpose  of  Stage  1  is  to  ensure  that 
needs  are  validated  as  requirements  using 
a  defined,  rigorous  process  based  on 
program  office  priorities.  This  stage  brings 
much  greater  discipline  into  the  acquisi¬ 
tion  process  (the  reengineering  team  had 
found  that  previously  there  was  no 
measurement  of  when  or  how  a  need  was 
validated  and  became  a  requirement).  By 
formalizing  the  process,  senior  manage¬ 
ment  is  aware  of  the  need  and  the  justifi¬ 
cation  for  the  validation  of  that  need.  Each 
need  is  identified  and  evaluated  using 
established  criteria,  then  validated  as  a 
requirement  by  the  affected  program  man¬ 
ager.  The  benefits  of  the  need  validation 
stage  are  that  the  new  process  provides 
structure  and  discipline  to  the  formerly 
vague  requirements  validation  process.  It 
requires  project  officers  to  clearly  define 
potential  requirements  and  encourages  the 


program  manager  to  filter  out  extraneous 
changes. 

Stage  2:  Solution  Definition 

The  purpose  of  Stage  2  is  to  identify 
the  best  solution  based  on  the  impact  on 
technical  capability,  sustainability,  cost, 
schedule,  and  risk  to  the  program.  Under 
this  stage,  the  project  team  is  formed  and 
reviews  the  requirement,  evaluates  alter¬ 
native  solutions,  and  provides  a  recom¬ 
mended  solution,  which  it  then  presents 
to  the  solution  validation  board  in  the  form 
of  a  solution  validation  briefing.  The  team 
also  develops  a  project  schedule  and 
begins  preparing  documentation,  such  as 
the  statement  of  work  (SOW),  and  draft 
Request  For  Proposal  (RFP).  The  project 
team  consists,  at  a  minimum,  of  the  project 
officer,  buyer, j 

budget  analyst,  contract  change 

contractor,  and  process  thal  ndute4 

end  military  cycle  time  for  the 
user.  Depend-  Launch  Programs 
ing  on  the  scope  system  program 
and  complexity  office  is  organized 

of  the  project,  into  six  stages.^ 
the  team  may 
also  include 

representatives  from  Configuration  Man¬ 
agement,  Defense  Contract  Management 
Command  (DCMC),  Defense  Contract 
Audit  Agency  (DCAA),  legal  counsel,  and 
other  agencies  as  necessary  at  this  stage 
of  the  process. 

The  benefits  of  this  stage  result  from 
the  combined  expertise  of  the  project  team 
developing  a  coordinated,  well-defined, 
and  understood  solution  that  best  meets 
mission  needs  and  prevents  ambiguity  in 
either  the  technical  or  contractual  require¬ 
ments.  Establishing  a  project  schedule 
early  in  the  change  process  also  keeps  the 
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•  Identify  need 

•  Conduct  horizontal 
effectiveness  assessment 

•  Validate  need  as  a 
requirement 

•  Inform  upper  management 


Conduct  call  to  action 
meeting 

Identify  alternatives  and 
determine  solution 

Develop  project  documents 
and  strategies 

Finalize  solution  validation 
briefing 


Complete  and  issue  RFCPP 

Develop  and  review  proposal 
elements 

Submit  proposal  and  complete 
evaluation  reports 

Update  and  coordinate  CCAR 


•  Prepare  initial  CCAR 


•  Validate  and  prioritize 
solution 


•  Inform  upper  management 

•  Initiate  contract  modification 
and  file 


j; 


Stages 

Stage  6 

Proposal 

Contract 

Contract 
Modification, 
Signature,  and 
Distribution 

Disposition 

■i 

Modification 

Completion 

■ 

•  Prepare  CCB  briefing 

•  Prepare  PNM 

•  Prepare  business  clearance 
briefing 

•  Complete  draft  contract 
modification(s) 

•  Evaluate  dollar  threshold 

•  Conduct  CCB  briefing 

•  Conduct  business  clearance 
review 


•  Reach  agreement 

•  Complete  PNM 

•  Issue  negotiation  letter 

•  Submit  CCCPD 

•  Update  and  coordinate  CCAR 

•  Approve  PNM 

•  Issue  purchase  request 

•  Update  and  review  contract 
file 


Review  contract  for  legal 
sufficiency 

Sign  contract  modification 

Conduct  review  and  contract 
clearance 


•  Award  and  distribute 
modification 


Figure  1.  The  Contract  Change  Process 
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team  focused  and  helps  avoid  “lagging’’ 
requirements.  Finally,  communication  of 
the  requirement  to  stakeholders  in  the 
acquisition  process  allows  the  team  mem¬ 
bers  to  prepare  for  and  address  potential 
budget,  contracting,  legal,  or  other  issues 
immediately. 

Stage  3:  Proposal  Request, 

Preparation,  and  Review 

The  purpose  of  Stage  3  is  to  issue  the 
RFP,  develop  and  incrementally  review 
the  technical  and  cost  elements  of  the 
proposal  with  the  prime  contractor,  and 
submit  the  final  proposal.  This  stage  is  the 
most  significant  because  it  brings  the 
government  acquisition  process  closer  to 
commercialization  by  working  together 
with  the  contractor  to  develop  a  proposal. 
The  60-day  waiting  period,  during  which 
the  contractor  develops  a  proposal  based 
on  the  RFP,  is  eliminated.  The  contractor 
does  not  work  in  a  vacuum  to  develop  his 
proposal  but  works  with  the  government 
engineers  to  establish  the  labor  skills  and 
mixes  and  hours  for  the  proposal.  The 
contractor  also  works  with  the  DCMC  and 
DCAA  on  material  and  rates  and  factors 
for  the  proposal.  Under  this  stage,  a 
preliminary  agreement  is  reached  between 
the  parties  on  the  proposal  before  it  is 
submitted:  all  are  in  agreement  prior  to 
submittal  of  the  contractor’s  proposal. 

As  mentioned  above,  the  project  team 
issues  the  RFP,  then  works  with  the  con¬ 
tractor  to  review  the  proposal  incremen¬ 
tally  as  it  is  being  developed.  The  proposal 
development  process  for  Stage  3  has  three 
reviews.  The  reviews  are  similar  to  a  30 
percent,  60  percent,  and  90  percent  review 
done  during  certain  types  of  acceptance 
testing.  The  initial  review  (when  30  per¬ 
cent  of  the  estimated  effort  is  completed 


for  the  proposal)  ensures  that  the  contrac¬ 
tor  understands  the  technical  requirement 
and  solution.  The  contractor  then  devel¬ 
ops  labor  and  material  estimates.  The 
majority  of  concurrent  fact-finding  is  done 
in  the  middle  review  (when  60  percent  of 
the  estimated  effort  for  the  proposal  is 
complete),  in  which  the  project  team, 
including  the  contractor,  reviews  the 
contractor’s  basis  of  estimates  (BOEs)  to 
achieve  consensus  on  labor  hours,  engi¬ 
neering  category  and  skill  level,  materi¬ 
als,  and  subcontractor  effort.  The  team 
reviews  the  BOEs  to  achieve  consensus 
on  all  issues. 


The  middle  re¬ 
view  is  critical 
because  at  this 
stage  of  the  pro- 
cess  the  team 


"This  stage  (3)  is 
the  most  significant 
because  it  brings  the 
government  acquisi¬ 
tion  process  closer 


resolves  the  ma-  to  commercialization 
jority  of  the  is-  by  working  together 
sues.  Between  with  the  contractor 

the  middle  and  *°  develop  a 
final  reviews,  ProPos<l*v 
the  team  will 

resolve  any  remaining  open  issues.  The 
final  review  (when  90  percent  of  the  esti¬ 
mated  effort  for  the  proposal  is  complete) 
is  to  resolve  any  outstanding  issues  prior 
to  proposal  submittal. 

Representatives  from  DCMC  and 
DCAA  also  support  reviews  of  the  pro¬ 
posals  over  the  $500,000  threshold,  and 
begin  the  price  analysis  report  and  audit 
at  this  time.  The  audit  is  done  incremen¬ 
tally  and  the  final  report  is  not  the  tradi¬ 
tional  thick  package  that  the  DCAA  usu¬ 
ally  issues.  For  this  process,  the  DCMC 
comes  to  an  understanding  with  the  con¬ 
tractor  on  the  kinds  and  quantities  of 
material  before  the  proposal  is  submitted 
to  the  government.  The  auditor  then  issues 
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a  memorandum  to  the  buyer  stating  that 
he  is  in  agreement  with  the  kinds  and 
quantities  of  material  to  be  presented  in 
the  resulting  proposal.  By  using  this  pro¬ 
cess,  Launch  Programs  has  eliminated  the 
classic  audit  report  and  lead  times  associ¬ 


ated  with  the  submittal  of  an  audit  report. 

Once  consensus  is  achieved,  the  con¬ 
tractor  submits  the  final  proposal,  which 
is  then  accepted  as  written  by  the  govern¬ 
ment — another 


"The  MOA  is  an 
intergovernmental 
and  quasi- 
organizational 
agreement  between 
the  DCMC,  DCAA, 
the  contractor,  and 
the  program  office 
on  the  acquisition 
process." 


significant  idea 
implemented  by 
Launch  Pro¬ 
grams.  In  order 
to  accept  the 
proposal  as  sub¬ 
mitted,  the  con¬ 
tractor  must 
submit  the  pro¬ 
posal  in  accor¬ 
dance  with  the 


consensus  building  and  audit  agreements, 
and  in  accordance  with  the  established 
memorandum  of  agreement  (MOA)  be¬ 
tween  the  organizations. 

The  MOA  is  an  intergovernmental  and 
quasi-organizational  agreement  between 
the  DCMC,  DCAA,  the  contractor,  and  the 
program  office  on  the  acquisition  process. 
It  details  the  acquisition  process,  each 
organization’s  responsibilities  to  the 
acquisition  process,  and  a  rate  agreement 
between  the  parties.  The  MOA  is  the  road 
map  for  the  reengineered  process.  The 
MOA  is  similar  to  a  team  charter.  There  is 
also  a  section  in  the  MOA  that  discusses 
rates  and  factors.  This  section  details  the 
process  when  there  are  forward  pricing 
rate  agreements  (FPRAs)  and  what  must 
be  accomplished  in  the  case  when  there 
are  no  FPRAs.  Profit  rates  are  not  specifi¬ 
cally  addressed  in  the  MOA.  What  is 


agreed  to  between  the  parties  in  the  MOA 
are  the  rates  and  factors  that  are  entered 
in  the  DoD  Form  1861  (weighted  guide¬ 
lines  form).  The  MOA  conforms  to  all 
acquisition  regulations  and  is  an  innova¬ 
tive  approach  to  resolving  the  rate  and 
factor,  and  profit  differences  that  usually 
occur  between  the  parties.  Therefore,  if 
you  have  agreement  on  labor  hours  and 
material,  and  agreement  on  the  rates  and 
factors  for  labor  and  overheads,  and  agree¬ 
ment  on  rates  and  factors  for  determining 
profit,  then  when  the  contractor  submits 
the  proposal  in  accordance  with  these 
agreements,  the  government  can  accept  the 
proposal  as  submitted  by  the  contractor. 

The  benefits  of  this  stage  show  that  the 
team  achieves  consensus  on  the  technical, 
cost,  and  contractual  elements  of  the 
contractor’s  proposal  through  teamwork, 
understanding,  and  communication  during 
the  proposal  preparation  process.  Without 
the  openness  and  teamwork  of  working 
for  the  common  good  of  both  organiza¬ 
tions,  the  incremental  review  of  the  pro¬ 
posal  would  not  be  a  productive  activity. 
The  key  to  consensus  building  is  under¬ 
standing  and  communication  of  the 
proposal  and  the  requirements,  so  that 
everyone  understands  the  logical  way  to 
proceed  to  satisfy  the  requirements.  By 
working  together  on  the  proposal,  quality 
is  built  in  so  there  are  no  costly  revisions 
or  fact-finding  to  understand  the  require¬ 
ments  or  meaning  of  the  proposal.  The 
contractor’s  final  proposal  is  then  accepted 
as  written,  avoiding  numerous  revisions 
and  added  cycle  time. 

Stage  4;  Proposal  Disposition 

The  purpose  of  Stage  4  is  to  prepare 
for  and  conduct  the  configuration  control 
board  (CCB)  and  business  clearance.  In 
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this  stage,  the  project  officer  leads  the  team 
in  concurrent  preparation  of  the  price 
negotiation  memorandum  (PNM),  CCB 
briefing  package,  and  business  clearance 
briefing.  This  step  combines  both  brief¬ 
ings.  The  benefit  of  combining  CCB  and 
business  clearance  eliminates  another 
coordination  step  in  the  contract  change 
process,  saving  time  and  using  existing 
forums  most  efficiently. 

Stage  5:  Contract 
Modification  Completion 

Stage  5  is  to  ensure  that  a  final  agree¬ 
ment  has  been  reached  between  the  con¬ 
tractor  and  the  project  team,  and  to  put 
that  agreement  is  in  writing.  Once  the 
proposal  has  been  approved  through  CCB 
and  business  clearance,  the  contractor  and 
buyer  confirm  the  agreement  and  the 
contractor  forwards  the  confirmation  of 
negotiations  letter  and  certification  of 
current  cost  or  pricing  data  (CCCPD). 

The  benefits  from  this  stage  show  there 
are  few  changes  required  because  the 
majority  of  the  effort  and  coordination 
has  been  completed  in  earlier  stages. 
Traditional  protracted  negotiations  are 
noticeably  absent. 


in  this  stage  of  the  process,  which  con¬ 
tributes  to  streamlining  efforts.  It  should 
be  noted  that  coordination  earlier  in  the 
process  would  expedite  processing  of  the 
modification. 

The  benefits  of  this  stage  show  that 
having  the  legal  office  review  the  modifi¬ 
cation  file  for 
legal  sufficiency 
prior  to  obtain¬ 
ing  contractor’s 
signature  saves 
valuable  trans¬ 
mittal  time  in 
the  event  the 

lawyer  finds  a  discrepancy.  Furthermore, 
the  legal  office  has  already  been  engaged 
during  Stage  3  (proposal  preparation),  and 
coordinated  on  any  special  contract 
provisions  or  other  legally  sensitive  issues 
to  make  this  final  review  pro  forma.  Dis¬ 
tribution  of  the  modification  has  not 
changed  under  this  process.  The  contract 
change  process  is  complete  and  ends  after 
this  activity. 


"The  objective  off 
the  Launch  Programs 
SPO  was  to  develop 
and  improve  the 
acquisition  process." 


Validation  of  Launch 
Program's  Reengineering  Goals 


Stage  6:  Contract  Modification 
Signature  and  Distribution 

The  purpose  of  Stage  6  is  to  review  the 
contract  modification  for  legal  sufficiency 
and  compliance  with  policies  and  regula¬ 
tions,  and  to  ensure  that  the  modification 
file  is  complete  and  accurate.  In  this  stage 
the  contract  clearance  authority  obtains  the 
contractor’s  signature  on  the  modification, 
and  the  procuring  contracting  officer 
awards  the  modification.  The  buyer  then 
distributes  the  completed  modification  to 
the  affected  parties.  There  are  few  changes 


The  reengineered  process  defined 
specific  improvement  areas  targeted  by 
the  Launch  Programs  SPO  director.  The 
goal  of  the  SPO  was  to  make  business 
management  a  part  of  Launch  Programs 
culture. 

The  objective  of  the  Launch  Programs 
SPO  was  to  develop  and  improve  the 
acquisition  process.  The  reengineered 
process  has  improved  the  cycle  times  of 
the  acquisition  process;  the  following 
analysis  validates  the  results  of  using  this 
streamlined  method. 


93 


Acquisition  Review  Quarterly — Winter  1 999 


Launch  Programs  correctly  anticipated 
the  need  for  more  control  in  the  require¬ 
ments  process,  and  enhanced  controls 
were  put  in  place  in  the  reengineered 
process.  These  new  controls  reduced  up¬ 
front  cycle  times  for  the  contract  change 
process. 

The  objectives  of  the  reengineering 
effort  were  achieved  and  implemented 
throughout  the  Launch  Programs  SPO. 

The  acquisition 


process  was 
streamlined  and 
it  has  reduced 
process  cycle 
times.  The  fol¬ 
lowing  analysis 
will  look  at  the 
achievements  of  the  Launch  Programs 
SPO  using  a  program  evaluation  review 
technique  (PERT)  analysis  to  validate  the 
hypothesis. 


"The  acquisition 
process  was 
streamlined  and 
it  has  reduced 
process  cycle 
times." 


Hypothesis 


The  Delta  II IPT  processes  five  to  seven 
ECPs  per  year.  A  random  sample  of  five 
ECPs  that  were  completed  with  the  tradi¬ 
tional  process  and  five  ECPs  that  were 
completed  using  the  new  reengineered 
process  were  chosen  for  this  analysis.  A 
government  tracking  system  (acquisition 
management  information  system  [AMIS]) 
was  used  to  track  the  progress  of  each 
ECP.  A  copy  of  the  AMIS  tracking  form 
is  included  in  each  ECP  file.  The  AMIS 
tracking  forms  used  in  this  analysis  are 
included  in  the  Appendix.  The  printouts 
list  very  specifically  the  various  mile¬ 
stones  that  must  be  completed  for  each 
ECP.  Since  AMIS  uses  the  traditional 
government  tracking  system,  there  is  a 
variance  between  milestones  in  the  two 
processes.  The  milestones  used  for  this 
analysis  are: 

•  Requirement  identified  ( Rl).  This  is  the 
date  the  government  identified  the  need 
for  a  change  to  an  existing  contract.  This 
date  is  the  same  for  both  processes. 


This  process  has  been  used  since  1995 
in  the  Delta  II  IPT,  when  it  was  initially 
proposed  to  reduce  cycle  times  by  50 
percent.  The  hypothesis  for  this  analysis 
is  whether  the  contract  change  process  re¬ 
duces  cycle  times  by  50  percent  or  more. 
The  antithesis  is  that  the  contract  change 
process  does  not  reduce  cycle  times  by  at 
least  50  percent. 

To  test  this  hypothesis,  a  PERT  analy¬ 
sis  was  used  to  determine  the  critical  path 
and  average  length  of  time  to  complete 
engineering  change  proposals  using  the 
traditional  and  reengineered  process,  and 
to  determine  the  average  cycle  time 
reduction  that  the  reengineered  process 
has  actually  achieved. 


•  Acquisition  strategy  panel  completion 
(ST).  This  is  the  activity  that  determines 
whether  the  change  is  in  scope  or  out 
of  scope  to  the  existing  contract.  For 
the  reengineered  process  this  is  the  date 
of  the  completion  of  Stage  2. 

•  Solicitation  issued  ( SI ).  This  is  the  date 
when  the  government  requests  a  pro¬ 
posal  from  the  contractor  (request  for 
proposal,  RFP).  This  date  is  the  same 
for  both  processes. 

•  Proposal/bids  received  (PR).  On  this 
date  the  contractor  submits  the  pro¬ 
posal  to  the  government.  This  date  is 
the  same  for  both  processes. 
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•  Price  evaluation/technical  evaluation / 
audit  completion  (PT).  This  is  the  date 
(the  same  for  both  processes)  when  all 
three  of  these  activities  have  been 
completed  by  government  personnel. 

•  Negotiations  completion( NC ).  The  date 
negotiations  are  complete  between  the 
parties.  Under  the  reengineered  process 
this  is  the  date  of  final  consensus  un¬ 
der  Stage  3. 

•  Contract  fde  completion  ( CF).  This  is 
the  date  when  the  file  is  complete  and 
ready  for  management  review.  This 
date  is  the  same  for  both  processes. 

•  Contract  writing  completion( CW).  On 
this  date  (the  same  for  both  processes) 
the  file  has  been  reviewed  and  is  ready 
for  the  contractor’s  signature. 

•  Contractor  signed  ( KS).  This  date,  the 
same  for  both  processes,  is  when  the 
contractor  signed  the  ECP. 

•  Legal  review  completion  (JR).  This  is 
the  final  review  of  the  modification  by 
a  government  contracts  lawyer  for  le¬ 
gal  sufficiency.  This  is  required  for 
modifications  over  $500,000.  This  date 
is  the  same  for  both  processes. 

•  Procurement  contracting  officer  signed 
(PS).  This  date,  the  same  for  both  pro¬ 
cesses,  is  when  the  contracting  officer 
for  the  government  approved  the 
change  and  obligated  the  money. 

On  the  AMIS  tracking  form  (see 

Appendix  A),  next  to  each  milestone  is  the 

scheduled,  forecast,  and  actual  date  that 

the  milestone  was  completed  for  the  ECP. 


The  actual  date  is  the  one  used  to  calcu¬ 
late  the  amount  of  time  it  took  to  com¬ 
plete  each  task.  All  the  dates  from  the 
AMIS  tracking  forms  were  converted  into 
numerical  data  (how  many  weeks  it  took 
to  complete  each  activity)  and  recorded 
on  a  spreadsheet  (Appendix  B).  The  result 
was  a  spreadsheet  that  calculated  the  time 
for  each  activity  per  ECP,  the  total  time 
per  ECP,  and  the  average  time  to  complete 
each  of  the  five  ECPs. 

The  spreadsheet  was  further  expanded 
by  performing  the  PERT  analysis  as 
described  in  Quantitative  Approaches  to 
Management  (Levine,  Rubin,  Stinson,  and 
Gardner ,  1 992).  Spreadsheet  Column  T(  1 ) 
is  the  streamlined  approach,  Column  T(2) 
is  the  average  time  for  ECPs,  and  Column 
T(3)  is  the  worst 
case  for  each 

activity.  From  resw*t was  u 

these  T  values  it  spreadsheet  that 

calculated  the  time 
for  each  activity  per 
KP,  the  total  time 
per  ECP,  and  the 
average  time  to 
complete  each  of  the 
five  ECPs." 


is  possible  to 
calculate  the  ex¬ 
pected  time  and 
the  standard  de¬ 
viation  for  each 
task. 

The  next  step 
of  the  PERT 


analysis  was  to  make  a  “forward  pass” 
through  the  network  to  determine  the 
earliest  start  and  finish  times  for  each 
activity.  A  “backward  pass”  was  then 
completed  through  the  network  to  find  the 
latest  start  and  finish  times  for  each  activ¬ 
ity.  By  comparing  these  passes  through  the 
network,  the  amount  of  slack  time  for  each 
activity  can  be  determined.  Any  activities 
that  have  no  slack  time  are  on  the  critical 
path.  The  network  diagrams  for  each  pro¬ 
cess  were  drawn  using  the  Activity-on-the- 
Node  (A-O-N)  method  (Figure  2). 
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Figure  2 .  The  Old  ECP  Process 


The  variances  for  the  system  deal  with 
the  following  observations  about  the 
AMIS  tracking  form:  various  activities 
occur  in  a  serial  fashion  on  the  form;  how¬ 
ever,  there  are  several  areas  in  the  process 
where  work  can  be  completed  in  parallel. 
Any  time  an  activity  was  completed  on 
the  same  day  as  the  preceding  activity,  a 
time  of  zero  was  entered  for  time  of 
completion  of  that  activity.  The  serial 
nature  of  events  on  the  AMIS  tracking 
form  only  considers  the  traditional  acqui¬ 
sition  process,  but  there  were  several 
activities  under  the  reengineered  process 
that  occurred  out  of  the  traditional 


sequences.  These  variations  were 
observed  in  this  analysis  and  considered 
in  the  findings  presented  for  the  reduction 
in  cycle  time. 

It  should  also  be  noted  that  there  are  no 
times  listed  for  “requirements  identified,” 
as  this  is  the  starting  point  of  the  network 
and  by  default  it  is  on  the  critical  path. 
The  AMIS  form  tracks  the  contracting 
activities  from  this  point.  For  RI  there  is 
no  validated  starting  point  and  in  our 
research  we  could  not  find  any  cycle  times 
related  to  the  beginning  of  any  procure¬ 
ment  activity  in  the  traditional  acquisition 
process  studied  for  this  paper.  In  the 
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reengineered  process,  in  theory,  you  can 
track  the  RI  time  from  the  beginning  of 
the  Stage  1  briefing  to  the  conclusion  of 
the  Stage  2  briefing  as  the  RI  time  for  the 
reengineered  process.  Since  the  reengi¬ 
neered  process  is  not  adapted  to  AMIS, 
there  is  no  data  for  the  specific  stages  in 
the  reengineering  process.  Therefore,  this 
analysis  is  constrained  by  the  traditional 
process  of  project  scheduling  for  ECPs. 

Critical  Paths 


Traditional  Process 

The  activities  necessary  to  complete 
ECPs  using  the  traditional  acquisition  pro¬ 
cess  were  more  serialized  and  required 
more  milestones  to  be  completed  before 
awarding  a  modification.  The  serial  pro¬ 
cess  resulted  in  much  higher  average  cycle 
times.  The  average  cycle  time  under  the 
traditional  process  was  46.5  weeks  for  an 
ECP  with  an  average  value  of  $700,000. 


Table  1  below  shows  the  results  of  the 
PERT  analysis  (Appendix  B). 

The  numerical  analysis  for  the  tradi¬ 
tional  process  found  two  activities  on  the 
critical  path  that  took  a  very  long  time  to 
complete.  The  PT  and  NC  activities  took 
approximately  11  weeks  and  12  weeks  to 
complete,  respectively.  These  two  activi¬ 
ties  combined  took  more  time  to  complete 
than  the  average  engineering  change 
proposal  under  the  reengineered  process. 

It  is  also  important  to  note  that  several 
of  the  activities  had  a  high  standard 
deviation  associated  with  the  degree  of 
uncertainty  in  the  calculated  expected  time 
to  completion  values.  The  high  standard 
deviations  reflect  the  spread  of  the  low  and 
high  values  in  the  columns  T(l)  and  T(3). 

The  lack  of  consistency,  lack  of  team¬ 
work,  and  the  potential  adversarial  rela¬ 
tionships  in  the  traditional  process  may 
lead  to  the  large  difference  between  the 
expected  and  required  time  to  complete 
some  activities.  The  unquantifiable 


Table  1.  Results  of  PERT  Analysis  of  Old  ECP  Process 


Activity 

Average 

Time 

Expected 

Time 

Standard 

Deviation 

Slack 

Time 

Critical 

Path? 

RI 

— 

— 

— 

— 

Y 

ST 

3.51 

5.1 

0.0 

Y 

SI 

0.83 

mmmm 

6.6 

Y 

PR 

6.46 

4.0 

PT 

11.11 

11.0 

3.31 

0.0 

Y 

NC 

12.31 

12.2 

1.76 

0.0 

CF 

3.51 

3.7 

0.98 

0.0 

0.26 

0.3 

0.12 

— 

1.09 

1.3 

0.50 

Y 

JR 

99 

4.69 

PS 

0.2 

0.07 

mm m 

Y 

Total  time 

46.48 

Value  (dollars) 

690,484 

a All  times  in  weeks. 
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relationships  between  the  parties  directly 
affect  the  quantitative  analysis  of  the  criti¬ 
cal  path  and  leads  one  to  believe  that  a 
better  relationship  may  reduce  cycle  times. 
Since  this  cannot  be  rationally  defined  in 
numerical  terms,  the  analysis  drew  a 
conclusion  from  existing  evidence  that 
external  factors  may  affect  the  standard 
deviation. 

Reengineered  Process 

The  reengineered  process  reveals  that 
it  requires  more  of  the  work  to  be  com¬ 
pleted  up  front  and  many  of  the  milestones 
can  be  completed  by  working  activities  in 
parallel.  It  can  be  concluded  that  the  ability 
to  work  activities  in  parallel  and  front¬ 
loading  the  process  adds  value  to  the 
reengineered  process  and  reduces  the 
average  cycle  times.  The  average  time  to 
complete  an  ECP  under  the  reengineered 
process  was  17  weeks.  The  average  value 
of  the  ECPs  that  participated  in  the 
reengineered  process  was  $4.4  million. 


This  reduction  in  cycle  time  represents, 
approximately,  a  63  percent  reduction  in 
time  required  to  complete  ECPs.  It  also 
demonstrates  that  high-value  ECPs  can  be 
processed  quickly  and  efficiently  in  the 
reengineered  process.  The  ECPs  analyzed 
for  the  reengineered  process  are  on  aver¬ 
age  6.5  times  greater  in  value  than  those 
ECPs  analyzed  in  the  traditional  process. 
This  is  important  to  note  because  typically 
the  larger  the  value  of  the  ECP,  the  greater 
the  amount  of  review  it  receives  in  the 
process.  Without  looking  at  an  equally 
high-value  ECP  in  the  traditional  process 
it  is  hard  to  conclude  that  the  higher  value 
ECPs  impact  the  analysis.  What  this  may 
show  is  that  regardless  of  ECP  value,  the 
reengineered  process  streamlines  the 
contract  change  process. 

The  numerical  analysis  of  the  reengi¬ 
neered  process  network  diagram  reveals 
that  there  is  one  specific  task  on  the  criti¬ 
cal  path  that  took  a  long  time  to  complete 
(Table  2).  The  SI  activity  took  an  average 


Activity 

Average 

Time 

Expected 

Time 

£ _ _ _ 

Standard 

Deviation 

Slack 

Time 

Critical 

Path? 

Rl 

— 

— 

— 

— 

Y 

ST 

2.03 

2.8 

1.43 

8.2 

SI 

10.03 

11.0 

4.21 

0.0 

Y 

PR 

1.86 

1.8 

0.45 

0.0 

Y 

PT 

0.57 

0.6 

0.22 

0.2 

NC 

0.69 

0.8 

0.31 

0.0 

Y 

CF 

0.66 

0.7 

0.24 

0.0 

Y 

. CW 

0.14 

0.2 

0.12 

0.6 

KS 

0.57 

0.8 

0.38 

0.0 

Y 

JR 

0.31 

0.5 

0,07 

2.8 

PS 

0.26 

0.2 

0.07 

0.0 

Y 

Total  time 

17.12 

Value  (dollars) 

4,443,192 

a  All  times  in  weeks. 
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of  10  weeks  to  complete  with  the  reengi¬ 
neered  process.  Further  analysis  shows 
that  one  ECP  may  be  the  cause  for  this 
long  cycle  time.  The  SI  activity  for  ECP 
number  3  required  25  weeks  to  complete. 
This  ECP  was  delayed  due  to  higher  pri¬ 
ority  contract  actions  and  may  not  be  rep¬ 
resentative  of  the  true  streamlining  abili¬ 
ties  of  the  reengineering  process. 
Examination  of  the  raw  data  indicates 
that  after  work  was  resumed  on  the  ECP 
it  was  completed  within  normal  cycle 
times  for  the  remaining  activities  in  the 
reengineered  process. 

It  is  also  important  to  note  that  several 
of  the  new  process  activities  had  a  high 
standard  deviation  associated  with  the 


degree  of  uncertainty  in  the  calculated 
expected  time  to  completion  values.  The 
high  standard  deviations  reflect  the  spread 
of  the  low  and  high  values  in  the  columns 
T(l)  andT(3)  (Appendix  B).  The  long  ac¬ 
quisition  strategy  panel  completion  activ¬ 
ity  of  more  than  8  weeks  for  ECP  number 
3  caused  the  high  standard  deviation  for 
that  activity.  There  were  scope  issues  that 
delayed  the  change  from  progressing 
within  the  streamlined  parameters.  The  long 
SI  activity  for  ECP  number  3  also  contrib¬ 
uted  to  the  high  standard  deviation  in  the 
reengineered  process  for  this  activity. 

From  the  analysis  of  the  new  process 
(Figure  3)  it  can  be  seen  that  external  fac¬ 
tors  also  influence  the  progression  of  cycle 


1 _ _ _ Ke*  1 

Rl 

requirement  identified. 

ST 

acquisition  strategy  panel  completion. 

SI 

solicitation  issued. 

PR 

proposals/bids  received. 

PT 

price  evaluation/technical  evaluation/audit  completion. 

NC 

negotiations  completion. 

□ 

contract  file  completion. 

cw 

contract  writing  completion. 

KS 

contractor  signed. 

legal  review  completion. 

m 

procuring  contracting  officer  signed. 

Figure  3.  The  New  ECP  Process 
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times.  These  real  world  examples  show 
that  regardless  of  the  best  efforts  on  the 
part  of  the  Delta  II IPT  to  streamline  the 

contract  change 

"...we  have 
determined  that  the 
activity  that  takes 
the  longest  amount 
off  time  to  complete 
under  the 


reengineered 
process  is  the 
issuance  of  the 
solicitation/' 


process,  there  is 
a  range  of  val¬ 
ues  that  can  be 
considered  ac¬ 
ceptable  for 
meeting  cycle 
times.  Prior  to 
this  analysis, 
these  values 
were  theoretical 


to  the  program 
office  and  it  was  not  until  this  PERT  analy¬ 
sis  of  cycle  times  was  completed  that  these 
theoretical  cycle  time  limits  could  be 
adopted  as  being  within  an  acceptable 
range  for  the  Launch  Programs  SPO’s  goal 
to  reduce  cycle  times.  This  PERT  analy¬ 
sis  was  also  very  useful  because  it  was  able 
to  quantify  an  actual  cycle  time  reduction 
of  the  reengineered  process. 


Conclusions 


The  PERT  analysis  illustrates  three 
important  points  about  the  reengineering 
process.  First,  the  63  percent  reduction  in 
cycle  times  actually  exceeds  the  initial 
goals  set  forth  by  the  reengineering  pro¬ 
cess  team.  The  PERT  analysis  verifies  the 
results  of  reengineering  and  proves  that 
the  new  process  contributes  greatly  to  the 
efficiency  of  the  acquisition  process.  The 
significant  reduction  in  cycle  time  also 
verifies  that  the  reengineered  process  is 
not  the  traditional  process  reordered  to  be 
more  effective. 

The  analysis  also  provides  insight  into 
the  formal  identification  of  the  critical  path 


for  each  process.  The  identification  of  the 
critical  path  for  the  traditional  process  was 
important  as  a  comparative  study  on  how 
reengineering  was  not  constrained  by  the 
traditional  critical  path  for  cycle  time 
improvements.  Understanding  the  critical 
paths  was  significant  in  streamlining  the 
acquisition  process,  and  understanding  the 
comparative  basis  of  each  process  is 
instructive  for  the  cultural  change  required 
within  the  program  office. 

The  final  point  derived  from  the  analy¬ 
sis  is  the  value  of  quantifying  the  activity 
time  on  the  critical  path  for  examination 
of  the  improvements  by  activities  rather 
than  at  the  aggregate  level.  This  analysis 
justifies  the  continued  use  of  the 
reengineering  process  for  Launch  Pro¬ 
grams  and  other  acquisition  organizations. 

As  a  result,  we  have  determined  that 
the  activity  that  takes  the  longest  amount 
of  time  to  complete  under  the  reengineered 
process  is  the  issuance  of  the  solicitation. 
Consequently,  management  should  focus 
on  this  activity  to  achieve  further  improve¬ 
ment.  This  is  within  the  control  of  the 
government.  The  other  activity  that 
requires  management  attention,  receiving 
a  proposal  from  the  contractor,  is  not 
within  the  government’s  control;  therefore 
it  is  incumbent  upon  contractors  to  take 
the  initiative  to  streamline  their  own 
internal  processes  to  compliment  the 
government  processes  in  streamlining  the 
acquisition  process. 

The  comparative  analysis  also  found 
that  the  activities  that  take  the  longest  in 
each  process  are  different.  One  would 
think  that  by  applying  efficiencies  to  the 
traditional  process  one  would  be  stream¬ 
lining  the  contract  change  process  and 
thereby  meeting  cycle  time  goals.  This 
was  not  the  case.  The  traditional  process 
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has  PT  and  NC  as  its  longest  activities. 
The  goal  of  the  reengineered  process  was 
to  front-load  the  process  to  end  the  lengthy 
technical  evaluation  and  negotiation  phases. 
This  was  achieved,  but  it  seems  that  effi¬ 
ciencies  were  lost  in  SI  and  PR  activities 
under  the  reengineered  process.  Again, 
this  can  be  explained  by  the  front-loading 
structure  of  the  process.  By  working  with 
the  contractor  up  front  to  have  a  proposal 
that  can  be  accepted  as  submitted  to  elimi¬ 
nate  traditional  negotiations,  the  consen¬ 
sus-building  process  extended  the  cycle 
time  to  compensate  for  such  efficiency. 

If  you  discard  the  traditional  process 
and  work  within  the  reengineering  pro¬ 
cess,  the  spreadsheet  Column  T(l)  (Ap¬ 
pendix  B)  times  are  being  met  in  most 
cases,  and  therefore  the  comparison  is  not 
equivalent  to  improving  the  efficiencies 
of  the  traditional  process.  The  goal  of 
reengineering  is  to  make  organizations 
“think  out  of  the  box”  and  discard  the 
traditional  process  for  the  new 
reengineered  process.  This  is  what  the 
Launch  Programs  SPO  accepted  in 
streamlining  the  acquisition  process. 

The  two  keys  to  consistently  imple¬ 
menting  the  reengineering  process  over 
many  programs  are  teamwork  and 
consensus  building.  A  team  methodology 
better  defines  and  validates  the  need  as  a 
requirement.  It  brings  structure  up  front 
in  the  process  and  allows  for  better 
communication  between  organizations. 

Consensus  building  combines  proposal 
building  and  evaluation  to  obtain  consen¬ 
sus  prior  to  the  formal  submission  of  the 
proposal.  The  incremental  reviews  allow 
the  team  to  work  out  problems  and  reach 
a  common  understanding  of  the  work 
being  performed  and  the  tasks  needed  to 
complete  the  effort.  Launch  Programs  has 


also  made  improvements  in  the  CCB  and 
business  clearance  subprocesses  to 
complement  changes  in  the  requirements 
definition  and  contract  consensus  subpro¬ 
cesses.  Finally,  the  acquisition  process  has 
been  standardized  over  all  Launch 
Program  IPTs  to 
shorten  the  ac¬ 
quisition  process 
in  duration  and 
increase  work¬ 
place  efficiency. 

The  results  of 
the  PERT  analy¬ 
sis  show  the  criti¬ 
cal  path  neces¬ 
sary  to  stream¬ 
line  the  acquisition  process.  The  analysis 
identifies  activities  with  long  cycle  times 
to  management  and  thus  shows  which 
activities  require  attention.  Finally,  the 
analysis  validates  the  hypothesis  that  the 
reengineering  process  has  reduced  cycle 
times  by  at  least  50  percent.  The  findings 
indicate  that  cycle  times  have  been 
reduced  by  an  average  of  63  percent  and 
with  added  efficiencies  it  is  believed  that 
Launch  Programs  could  achieve  a  70 
percent  cycle-time  reduction. 


"The  two  keys  to 
consistently  imple¬ 
menting  the 
reengineering  ; 
process  over  many 
programs  are  team¬ 
work  and  consensus 
building" 


Lessons  Learned 

The  analysis  laid  out  here  shows  that: 

•  It  is  important  to  empower  people  at 
lower  levels. 

•  It  is  vital  to  remove  unnecessary  and 
non-value-added  policies,  rules,  and 
regulations. 

•  Development  of  a  low  value  checks 
and  balances  system  streamlines  cycle 
times. 
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The  need  to  empower  people  at  lower 
levels  is  critical  in  today’s  downsizing 
environment.  The  reengineered  IPT 
recognized  this  tenet  and  successfully 
integrated  it  into  the  process.  The  process 

empowered 


"The  need  to 
empower  people 
at  lower  levels  is 
critical  in  today's 
downsizing 
environment." 


people  at  lower 
levels  by  giving 
the  project  of¬ 
ficer  the  respon¬ 
sibility  for  the 
process.  He  or 
she  is  empow¬ 


ered  to  define 
the  requirements,  gain  acceptance  of  the 
requirements  from  senior  management, 
agree  to  labor  and  material,  and  gain  ap¬ 
proval  for  the  contract  change.  The  work¬ 
ing-level  IPT  is  empowered  to  seek  agree¬ 
ment  on  terms  and  conditions. 

Another  valuable  lesson  is  the  impor¬ 
tance  of  removing  non-value-added 
policies,  rules,  and  regulations.  While  the 
reengineered  process  sought  deviations, 
review  by  senior  management  interpreted 
the  critical  ideas  of: 


•  only  one  price  negotiation  memoran¬ 
dum; 

•  one  clearance  review  approval; 

•  negotiated  rates  and  factors  for  profit 
guidelines;  and 

•  building  consensus  without  the  author¬ 
ity  to  negotiate,  as  legally  sufficient  and 
within  the  intent  of  existing  regulatory 
and  statutory  requirements. 

The  reengineered  process  has  benefited 
from  acquisition  reform  and  allowed  the 
visionaries  in  the  government  to 


implement  reforms  with  positive  and 
innovative  results. 

The  final  lesson  learned  from  the  analy¬ 
sis  is  that  in  order  to  streamline  the  acqui¬ 
sition  process,  there  must  be  a  low-value 
check  and  balance  system.  The  reengi¬ 
neered  process  initiated  a  “validation  of 
the  requirement”  briefing  to  adequately 
define  the  requirement  for  the  program. 
Another  check  was  the  single  clearance 
approval  briefing  prior  to  pursuing  con¬ 
tract  award.  This  review  is  similar  to  an 
“end  of  runway  check,”  to  review  that 
everything  is  in  order  and  makes  sense 
before  approving  the  change  and  issuing 
a  modification.  This  is  the  contract 
approval  authority’s  final  check  before  the 
requirement  is  incorporated  into  the 
contract.  Other  low-level  checks  and 
balances  include  the  contractor’s  partici¬ 
pation  in  the  CCB  briefing,  contractor’s 
participation  in  the  RFP  review  process, 
the  government’s  participation  in  the 
contractor’s  proposal  review  process,  and 
the  IPT’s  systematic  reviews  to  ensure 
consistency  and  completeness  to  the 
process.  These  checks  and  balances  were 
lacking  in  the  traditional  process,  which 
sought  one  definitive  briefing  for  each 
step.  The  key  use  of  teamwork  is  an 
invaluable  asset  to  the  reengineering 
process  when  developing  the  necessary 
checks  and  balances  to  streamline  cycle 
times. 

In  terms  of  program  effort  to  accom¬ 
plish  a  contract  modification,  additional 
program  effort  was  saved  by  the  fact  that 
the  reengineered  process  focuses  on  qual¬ 
ity,  the  first  time,  for  deliverables.  This 
first-time  quality  effort  for  the  RFP  and 
proposal  eliminates  revised  RFPs  to  the 
contractor  and  costly  proposal  revisions. 
Defining  the  requirement  in  the  IPT  and 
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the  single  focus  on  a  firm  requirement 
allows  all  participants  to  fully  understand 
the  scope  of  the  acquisition.  This  saves 
effort  in  costly  reinterpretation  of  the 
request  for  a  proposal  and  rewrites  of  con¬ 
tract  documents.  The  program  office  and 
the  contractor  agree  to  the  requirements 
and  the  solution.  The  IPT  is  then  tasked 
to  complete  a  contract  modification  to 
implement  the  solution.  There  is  a  signifi¬ 
cant  amount  of  effort  saved  when  there  is 
a  firm  requirement.  The  reengineered 
process  has  saved  the  program  additional 
effort  and  added  value  to  the  overall 
acquisition  process  through  these  lessons 
learned  by  the  Delta  II  IPT. 

The  reengineered  process  is  a  success — 
but  this  success  is  not  without  risks.  One 
risk — possible  perceptions  of  increased 
profit  to  the  contractor  from  agreed-to 


rates  in  the  memorandum  of  agreement — 
was  mitigated  by  the  fact  that  the  reverse 
actually  occurred.  The  contractor  needed 
to  hold  many  briefings  with  corporate 
authorities  to  show  the  process  benefits. 
Another  perceived  risk  is  the  concept  of 
empowering  people  at  the  lowest  level  to 
make  decisions  for  the  program.  However, 
the  delegation  of  responsibility  is  a  neces¬ 
sity  with  the  downsizing  of  government 
and  this  risk  is  mitigated  by  the  formal 
briefings  given  to  approval  authorities. 

In  today’s  downsizing  and  increasingly 
competitive  environment,  both  inside  and 
outside  the  government,  these  projects 
highlight  the  significant  accomplishments 
of  individuals  and  organizations,  and  their 
commitment  to  acquisition  reform  and  the 
idea  of  doing  business  faster,  cheaper,  and 
better. 
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ECP  #1 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
95SEP21  OWNED  BY:  SMC 


14:17 


PURCH-DESC:  3RD  STAGE  CONTROL  BOX 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT:  $800,029 

EXT-COMP:  A  COMPETED 

PROG-STAGE:  P  PRODUCTION 

SPECIAL-PRO:  N  NOT  APPLICABLE 

TYPE-CONT:  9  MULTIPLE  TYPES 

TYPE-ACT:  SA  SUPPLEMENTAL  AGREEMENT 

ACTION-STARTED:  940CT11 

NETWORK:  M4 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES  111 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $800,029 

SOL-PROC:  B  F&O  COMP-  COMP  PROPOSAL 

SS-CAT:  A  FORMAL  SS  AFFARS  APP  AA 

ARPA: 

FAST-TRK:  D  NOT  APPLICABLE 

STATUS:  I  IN-PROGRESS 

AGE:  345  CWAM  AGE:  337 

SCHEDULED-T1ME:  89 

KTR:  MCDONNELL  DOUGLAS  CORP 


MILESTONE 


Rl  REQUIREMENT  IDENTIFIED 

ST  ACQ  STRATEGY  PANEL  COMP 

SI  SOLICITATION  ISSUED 

PR  PROPOSALS/BIDS  RECEIVED 

PT  PRICE  ANAL/TECH  EVAL/AUDT 

NC  NEGOTIATIONS  COMPLETED 

CF  CONTRACT  FILE  COMPLETED 

CW  CONTRACT  WRITING  COMPLETE 

KS  CONTRACTOR  SIGNED 

JR  JAG  REVIEW  COMPLETED 

PS  PCO  SIGNED 

AM  AWARD  MAILED 


SCHEDULE 


940CT12 
940CT19 
95MAR14 
95MAR23 
95  MAY  19 
95MAY23 
95MAY24 
95MAY23 
95MAY29 
95MAY26 
95JUN08 
95JUN18 


FORECAST 


95FEB28 

95MAR07 

95MAR14 

95MAR23 

95MAY19 

95MAY23 

95JUL15 

95JUL14 

95JUL20 

95JUL17 

95JUL30 

95AUG09 


ACTUAL 


940CT12 

940CT19 

94NOV10 

94DEC09 

95FEB21 

95MAY31 

95JUL20 

95JUL24 

95AUG15 

95SEP19 

95SEP21 


LAST  PAGE  1 
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ECP  #2 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
95AUG10  OWNED  BY:  SMC 


12:32 


PURCH-DESC:  ADDITIONAL  ALCS  WORK  STATION 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT:  $274,566 

EXT-COMP:  C  FOLLOW  ON  TO  COMP  ACT 


PROG-STAGE: 

SPECIAL-PRO:  N 

TYPE-CONT:  9 

TYPE-ACT:  SA 

ACTION-STARTED: 

NETWORK:  M6 

PROGRAM:  MEDIUM  LAUNCH  VEHICLE 


NOT  APPLICABLE 
MULTIPLE  TYPES 
SUPPLEMENTAL  AGREEMENT 
95MAR20 


PCO: 


PEO-PROG: 

EST-TOT-AMOUNT:  $274,566 

SOL-PROC:  N  OTHER  THAN  F&O  COMP 

SS-CAT: 

ARPA: 


FAST-TRK:  D  NOT  APPLICABLE 

STATUS:  I  IN-PROGRESS 

AGE:  143  CWAM  AGE:  142 

SCHEDULED-TIME:  245 

KTR:  MCDONNELL  DOUGLAS  CORP 


MILESTONE 

SCHEDULE 

FORECAST 

ACTUAL 

Rl 

REQUIREMENT  IDENTIFIED 

95MAR21 

95MAR21 

95MAR21 

ST 

ACQ  STRATEGY  PANEL  COMP 

95MAY10 

95MAY10 

95MAR21 

SI 

SOLICITATION  ISSUED 

95JUN19 

95JUN19 

95MAR27 

PR 

PROPOSALS/BIDS  RECEIVED 

95AUG18 

95AUG18 

95APR27 

PT 

PRICE  ANAL/TECH  EVAL/AUDT 

950CT17 

950CT17 

95MAY02 

NC 

NEGOTIATIONS  COMPLETED 

950CT29 

950CT29 

95JUN29 

CF 

CONTRACT  FILE  COMPLETED 

95OCT06 

95OCT06 

95AUG01 

CW 

CONTRACT  WRITING  COMPLETE 

95NOV12 

95NOV12 

95AUG01 

JR 

JAG  REVIEW  COMPLETED 

95NOV23 

95NOV23 

95AUG01 

REMARKS:  NOT  APPLICABLE 

KS 

CONTRACTOR  SIGNED 

95NOV27 

95NOV27 

95AUG08 

PS 

PCO  SIGNED 

95NOV30 

95NOV30 

95AUG10 

AM 

AWARD  MAILED 

95DEC03 

95DEC03 
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ECP  #3 

*  *  PMS  BUYING  PLAN  REPORT  FOR 
95OCT05  OWNED  BY:  SMC 


PURCH-DESC:  BLOCK  IIA  LON  CAPABILITY 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT:  $3,011,064- 

EXT-COMP:  C  FOLLOW  ON  TO  COMP  ACT 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT:  9  MULTIPLE  TYPES 

TYPE-ACT:  DS  DEFIN  UNPRICED  SUPP  AGR 

ACTION-STARTED:  94SEP30 

NETWORK:  B7 

PROGRAM:  MEDIUM  LAUNCH  VEHICLE 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $1,324,752- 

SOL-PROC:  N  OTHER  THAN  F&O  COMP 

SS-CAT: 

ARPA: 

FAST-TRK: 

STATUS:  I  IN-PROGRESS 

AGE:  370  CWAM  AGE:  370 

SCHEDULED-TIME:  198 

KTR:  MCDONNELL  DOUGLAS  SPACE  SYS  CO 


MILESTONE 


SI  SOLICITATION  ISSUED 

PR  PROPOSALS/BIDS  RECEIVED 

FF  FACT  FINDING  COMPLETED 

DELAY:  XX 

REMARKS:  SLOW  REVIEW 
FR  FIELD  REPORTS  RECEIVED 

DELAY:  XX 

REMARKS:  SLOW  REVIEW 
BA  BUS  CLEARANCE  APPROVED 

DELAY:  XX  REFORECAST  95MAY24 

BC  BUS  CLEARANCE  REQUEST 

PT  PRICE  ANAL/TECH  EVAL/AUDT 

PA  PRICING  ANALYSIS  COMPLETE 

TE  TECH  EVAL  COMPLETED 

NC  NEGOTIATIONS  COMPLETED 

DELAY:  XX 

CF  CONTRACT  FILE  COMPLETED 

CW  CONTRACT  WRITING  COMPLETE 
JR  JAG  REVIEW  COMPLETED 

KS  CONTRACTOR  SIGNED 

AN  AWARD  ANNOUNCEMENT  - 1279 
CS  CONT  CLEARANCE  APPROVED 

PS  PCO  SIGNED 

AM  AWARD  MAILED 


SCHEDULE 

FORECAST 

ACTUAL 

94SEP30 

94SEP30 

94SEP30 

95JAN08 

95JAN08 

94DEC22 

95JAN29 

95JAN29 

95MAR17 

95FEB12 

95FEB12 

95MAY01 

95MAR05 

95MAR05 

95MAY15 

95MAR05 

95MAR05 

95  MAY  15 

95MAR09 

95FEB12 

95MAY17 

95FEB12 

95 FEB 12 

95MAY19 

95FEB12 

95FEB12 

95MAY19 

95APR02 

95SEP22 

95SEP13 

95MAY28 

95SEP29 

95SEP22 

95  MAY  14 

950CT13 

95SEP22 

95MAY28 

950CT13 

95SEP26 

95MAY28 

95OCT20 

95SEP28 

95MAY28 

950CT27 

95SEP28 

95MAY28 

95OCT06 

95SEP29 

95MAY28 

950CT27 

95SEP29 

95APR16 

950CT28 

UCA  INFORMATION 
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ECP  #4 


96MAY02 


*  ‘  PMS  BUYING  PLAN  REPORT  FOR 
OWNED  BY:  SMC 


11:49 


PURCH-DESC:  CCP  SELF  STUDY  GUIDE 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT: 

EXT-COMP: 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT: 

TYPE-ACT: 

ACTION-STARTED: 


A 

P 

N 

9 

SA 

M4 


$1 ,053,072 

COMPETED 

PRODUCTION 

NOT  APPLICABLE 

MULTIPLE  TYPES 

SUPPLEMENTAL  AGREEMENT 

94APR07 


NETWORK: 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES  III 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $1,053,072 


SOL-PROC: 

B 

’  F&O  COMP-  COMP  PROPOSAL 

SS-CAT: 

ARPA: 

A 

FORMAL  SS  AFFARS  APP  AA 

FAST-TRK: 

D 

NOT  APPLICABLE 

STATUS: 

A 

AWARDED 

AGE: 

736 

SCHEDULED-TIME:  89 

KTR:  MCDONNELL  DOUGLAS  CORP 


ACRN 

APPROP 

YR 

BPAC 

PEC 

AE 

3020 

4 

23MLVO 

351 19F 

OBLIGATED 

$1,053,072 


MILESTONE 

SCHEDULE 

FORECAST 

ACTUAL 

Rl 

REQUIREMENT  IDENTIFIED 

94APR08 

94JUN30 

94JUN30 

ST 

ACQ  STRATEGY  PANEL  COMP 

94APR15 

95JAN31 

940CT24 

SI 

SOLICITATION  ISSUED 

95FEB07 

95FEB07 

940CT24 

PR 

PROPOSALS/BIDS  RECEIVED 

95FEB16 

95FEB16 

94DEC14 

PT 

PRICE  ANAL/TECH  EVAL/AUDT 

95APR14 

95AUG11 

95  MAY0 1 

NC 

NEGOTIATIONS  COMPLETED 

DELAY:  XX 

95APR18 

95AUG15 

95AUG15 

CF 

CONTRACT  FILE  COMPLETED 

95APR18 

95AUG15 

95SEP01 

CW 

CONTRACT  WRITING  COMPLETE 

95APR18 

95AUG15 

95SEP06 

JR 

JAG  REVIEW  COMPLETED 

DELAY:  XX 

95APR18 

96JAN05 

96MAR29 

KS 

CONTRACTOR  SIGNED 

95APR19 

96JAN06 

96APR04 

PS 

PCO  SIGNED 

95APR20 

96JAN07 

96APR04 

AM 

AWARD  MAILED 

95APR22 

96JAN09 

96APR12 

LAST  PAGE  1 
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MILESTONE 


SCHEDULE  FORECAST  ACTUAL 


R1  REQUIREMENT  IDENTIFIED 

ST  ACQ  STRATEGY  PANEL  COMP 

SI  SOLICITATION  ISSUED 

PR  PROPOSALS/BIDS  RECEIVED 

PT  PRICE  ANAL/TECH  EVAL/AUDT 

NC  NEGOTIATIONS  COMPLETED 

CW  CONTRACT  WRITING  COMPLETE 
CF  CONTRACT  FILE  COMPLETED 

JR  JAG  REVIEW  COMPLETED 

KS  CONTRACTOR  SIGNED 

PS  PCO  SIGNED 

AM  AWARD  MAILED 


94FEB02 

94FEB09 

94APR13 

94APR13 

94APR15 

94MAY01 

94MAY10 

94MAY12 

94MAY15 

94MAY17 

94MAY18 

94MAY19 


94FEB01 

94APR13 

94APR13 

94APR13 

94APR15 

94MAY25 

94JUN03 

94JUN05 

94JUN08 

94JUN10 

94JUN11 

94JUN12 


94FEB01 

94FEB01 

94FEB01 

94MAR04 

94APR01 

94MAY18 

94MAY31 

94MAY31 

94JUN08 

94JUN09 

94JUN09 
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NEW  PROCESS 
ECP  #1 


97FEB26 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
OWNED  BY:  SMC 


12:51 


PURCH-DESC:  OB  GROUND  VEHICLE  SIMULATOR 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT: 

EXT-COMP: 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT: 

TYPE-ACT: 

ACTION-STARTED: 


A 

P 

N 

9 

SA 

M4 


$409,302 

COMPETED 

PRODUCTION 

NOT  APPLICABLE 

MULTIPLE  TYPES 

SUPPLEMENTAL  AGREEMENT 

96DEC18 


NETWORK: 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES 


PCO: 


PEO-PROG: 

EST-TOT-AMOUNT:  $409,302 

SOL-PROC:  B  F&O  COMP-  COMP  PROPOSAL 

SS-CAT:  A  FORMAL  SS  AFFARS  APP  AA 

ARPA: 


FAST-TRK:  D  NOT  APPLICABLE 

STATUS:  I  IN-PROGRESS 

AGE:  70  CWAMAGE:  70 

SCHEDULED-TIME:  63 

KTR:  MCDONNELL  DOUGLAS  CORPORATION 


MILESTONE 

SCHEDULE 

FORECAST 

ACTUAL 

Rl 

REQUIREMENT  IDENTIFIED 

97JAN01 

97JAN01 

96  DEC  18 

ST 

ACQ  STRATEGY  PANEL  COMP 

REMARKS:  LAUNCH  FAILURE  CAUSED  DELAY 

97FEB15 

97FEB15 

96DEC18 

SI 

SOLICITATION  ISSUED 

97FEB15 

97FEB15 

97JAN31 

PR 

PROPOSALS/BIDS  RECEIVED 

97MAR15 

97MAR15 

97FEB14 

PT 

PRICE  ANAL/TECH  EVAL/AUDT 

97MAR20 

97MAR20 

97FEB20 

NC 

NEGOTIATIONS  COMPLETED 

97APR01 

97APR01 

97FEB20 

AM 

AWARD  MAILED 

97MAY15 

97MAY15 
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NEW  PROCESS 
ECP  #2 


97MAY16 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
OWNED  BY:  SMC 


18:09 


PURCH-DESC:  BO  AIR  CONDITIONER  REPLACEMENT 


CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT: 

EXT-COMP: 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT: 

TYPE-ACT: 

ACTION-STARTED: 

NETWORK: 


A 

P 

N 

9 

SA 

M4 


$1,324,034 

COMPETED 

PRODUCTION 

NOT  APPLICABLE 

MULTIPLE  TYPES 

SUPPLEMENTAL  AGREEMENT 

960CT25 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $1,324,034 


SOL-PROC: 

SS-CAT: 

ARPA: 

FAST-TRK: 

STATUS: 

AGE: 


203 


F&O  COMP-  COMP  PROPOSAL 
FORMAL  SS  AFFARS  APP  AA 

NOT  APPLICABLE 
IN-PROGRESS 

CWAMAGE:  196 


PROGRAM:  MEDIUM  LAUNCH  VEHICLES  III 


SCHEDULED-TIME:  63 

KTR:  MCDONNELL  DOUGLAS  CORPORATION 


MILESTONE 


SCHEDULE  FORECAST  ACTUAL 


Rl 

REQUIREMENT  IDENTIFIED 

96  NOV0 1 

96NOV01 

ST 

ACQ  STRATEGY  PANEL  COMP 

96NOV01 

96NOV01 

REMARKS:  CHRISTMAS  BREAK  AND  LAUNCH  FAILURE  MAY  CAUSE  DELAY 

SI 

SOLICITATION  ISSUED 

97FEB01 

97MAY01 

REMARKS:  LAUNCH  FAIL  UCA  CAUSED  DELAY  01  MAR  REVISED  DATE 

PR 

PROPOSALS/BIDS  RECEIVED 

97MAR01 

97MAY01 

REMARKS:  KTR  MATERIAL  PROBLEMS  DELAYING  PROPOSAL 

PT 

PRICE  ANAL/TECH  EVAL/AUDT 

97MAR05 

97MAY05 

NC 

NEGOTIATIONS  COMPLETED 

97MAR15 

97MAY15 

JR 

JAG  REVIEW  COMPLETED 

97APR01 

97JUN01 

CS 

CONT  CLEARANCE  APPROVED 

97APR15 

97JUN15 

PS 

PCO  SIGNED 

97APR16 

97JUN16 

AM 

AWARD  MAILED 

97  MAY0 1 

97JUN27 

96NOV01 

96NOV01 

97APR29 

97MAY06 

97MAY08 

97MAY09 

97MAY13 

97MAY16 

97MAY16 


LAST  PAGE  1 
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NEW  PROCESS 
ECP  #3 


96FEB23 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
OWNED  BY:  SMC 


14:31 


PURCH-DESC:  OPS  BLDG.  EQUIPMENT 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT: 

EXT-COMP: 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT: 

TYPE-ACT: 

ACTION-STARTED: 


A 

P 

N 

9 

SA 

M4 


$16,750,884 

COMPETED 

PRODUCTION 

NOT  APPLICABLE 

MULTIPLE  TYPES 

SUPPLEMENTAL  AGREEMENT 

95SEP14 


NETWORK: 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES  III 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $19,786,825 


SOL-PROC: 

B 

F&O  COMP-  COMP  PROPOSAL 

SS-CAT: 

ARPA: 

A 

FORMAL  SS  AFFARS  APP  AA 

FAST-TRK: 

D 

NOT  APPLICABLE 

STATUS: 

1 

IN-PROGRESS 

AGE: 

162 

CWAMAGE:  101 

SCHEDULED-TIME:  63 

KTR;  MCDONNELL  DOUGLAS  CORP 


MILESTONE 

SCHEDULE 

FORECAST 

ACTUAL 

Rl 

REQUIREMENT  IDENTIFIED 

95SEP16 

95SEP16 

95SEP16 

DELAY:  XX  DELAY  DUE  TO  SCOPE  ISSUES 

ST 

ACQ  STRATEGY  PANEL  COMP 

95SEP20 

95OCT04 

95NOV14 

DELAY:  XX  REENGINEERING  PROCESS  MILESTONE  1 

SI 

SOLICITATION  ISSUED 

95DEC22 

96FEB29 

96JAN09 

DELAY:  XX  REENGINEERING  PROCESS  MILESTONE  2 

PR 

PROPOSALS/BIDS  RECEIVED 

96JAN15 

96MAR24 

96JAN30 

PT 

PRICE  ANAUTECH  EVAL/AUDT 

96JAN27 

96APR05 

96JAN30 

NC 

NEGOTIATIONS  COMPLETED 

96FEB05 

96APR14 

96JAN30 

CF 

CONTRACT  FILE  COMPLETED 

96FEB07 

96APR16 

96FEB09 

CW 

CONTRACT  WRITING  COMPLETE 

96FEB11 

96APR20 

96FEB09 

JR 

JAG  REVIEW  COMPLETED 

96FEB15 

96APR24 

96FEB16 

KS 

CONTRACTOR  SIGNED 

96FEB18 

96APR27 

96FEB20 

PS 

PCO  SIGNED 

96FEB23 

96MAY02 

96FEB22 

AM 

AWARD  MAILED 

96FEB25 

96MAY04 
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NEW  PROCESS 
ECP  #4 


96AUG06 


*  *  PMS  BUYING  PLAN  REPORT  FOR 
OWNED  BY:  SMC 


17:47 


PURCH-DESC:  SUPPLEMENTAL  AGREEMENT 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT:  $134,258 

EXT-COMP:  A  COMPETED 

PROG-STAGE:  P  PRODUCTION 

SPECIAL-PRO:  N  NOT  APPLICABLE 

TYPE-CONT:  9  MULTIPLE  TYPES 

TYPE-ACT:  SA  SUPPLEMENTAL  AGREEMENT 

ACTION-STARTED:  96JUL1 8 

NETWORK:  XX 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES  III 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $134,258 

SOL-PROC:  B  F&O  COMP-  COMP  PROPOSAL 

SS-CAT:  A  FORMAL  SS  AFFARS  APP  AA 

ARPA' 

FAST-TRK:  D  NOT  APPLICABLE 

STATUS:  I  IN-PROGRESS 

AGE:  19  CWAMAGE:  19 

SCHEDULED-TIME:  0 

KTR:  MCDONNELL  DOUGLAS  CORP 


MILESTONE 


Rl  REQUIREMENT  IDENTIFIED 

ST  ACQ  STRATEGY  PANEL  COMP 

SI  SOLICITATION  ISSUED 

PR  PROPOSALS/BIDS  RECEIVED 

PT  PRICE  ANAL/TECH  EVAL/AUDT 

NC  NEGOTIATIONS  COMPLETED 

KS  CONTRACTOR  SIGNED 

PS  PCO  SIGNED 

AM  AWARD  MAILED 


SCHEDULE  FORECAST  ACTUAL 


96JUL18 

96JUL18 

96JUL25 

96JUL26 

96JUL26 

96JUL29 

96JUL29 

96JUL29 

96JUL29 


96JUL18 

96JUL18 

96JUL25 

96JUL26 

96JUL26 

96JUL29 

96JUL29 

96JUL29 

96JUL29 


96JUL18 

96JUL18 

96JUL18 

96JUL18 

96JUL18 

96JUL29 

96JUL29 

96JUL30 
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NEW  PROCESS 
ECP  #5 


96SEP24 


*  *  PMS  BUYING  PU\N  REPORT  FOR 
OWNED  BY:  SMC 


17:20 


PURCH-DESC:  OB  CREDIT  MODIFICATION 
CURR-BUYER: 

CLERK: 

EST-OBL-AMOUNT: 

EXT-COMP: 

PROG-STAGE: 

SPECIAL-PRO: 

TYPE-CONT: 

TYPE-ACT: 

ACTION-STARTED: 


A 

P 

N 

9 

SA 

M5 


$561 ,540- 

COMPETED 

PRODUCTION 

NOT  APPLICABLE 

MULTIPLE  TYPES 

SUPPLEMENTAL  AGREEMENT 

96FEB17 


NETWORK: 

PROGRAM:  MEDIUM  LAUNCH  VEHICLES  III 


PCO: 

PEO-PROG: 

EST-TOT-AMOUNT:  $561,540- 


SOL-PROC: 

B 

F&O  COMP-  COMP  PROPOSAL 

SS-CAT: 

A 

FORMAL  SS  AFFARS  APP  AA 

ARPA: 

FAST-TRK: 

D 

NOT  APPLICABLE 

STATUS: 

1 

IN-PROGRESS 

AGE: 

220 

CWAM  AGE:  207 

SCHEDULED-TIME: 

154 

KTR:  MCDONNELL  DOUGLAS  CORP 


MILESTONE 

SCHEDULE 

FORECAST 

ACTUAL 

Rl 

REQUIREMENT  IDENTIFIED 

96FEB19 

96FEB19 

96FEB20 

ST 

ACQ  STRATEGY  PANEL  COMP 

96MAR04 

96MAR04 

96MAR01 

SI 

SOLICITATION  ISSUED 

96MAR12 

96  MAR  12 

96JUL20 

PR 

PROPOSALS/BIDS  RECEIVED 

96APR05 

96APR05 

96AUG01 

PT 

PRICE  ANAL/TECH  EVAL/AUDT 

96MAY13 

96  MAY  13 

96AUG10 

NC 

NEGOTIATIONS  COMPLETED 

96JUN15 

96JUN15 

96AUG20 

CF 

CONTRACT  FILE  COMPLETED 

96AUG23 

96AUG23 

96AUG30 

CW 

CONTRACT  WRITING  COMPLETE 

96AUG26 

96AUG26 

96SEP04 

KS 

CONTRACTOR  SIGNED 

96AUG30 

96AUG30 

96SEP20 

PS 

PCO  SIGNED 

96SEP04 

96SEP04 

96SEP23 

AM 

AWARD  MAILED 

96JUL20 

96SEP09 

LAST  PAGE  1 
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Appendix  B 


Pert  Analysis  of  Re-Engineered  Contract  Change  Process 
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PERT  Analysis  of  Re-Engineered  Contract  Change  Process 

Examination  will  focus  on  the  information  that  is  kept  in  a  centra!  contracting  database  called  AMIS.  This  database  i 
used  to  keep  track  and  record  the  progress  of  ECP's  as  they  move  through  the  contracting  process.  There  are  very 
specific  milestones  that  must  be  reached  for  each  ECP  to  be  put  on  contract.  These  are  the  milestones  that  are 
tracked  in  the  database  and  the  ones  that  will  be  used  in  the  PERT  analysis  as  the  specific  activities. 
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Guidelines  for  Contributors 


ACQUISITION  RCVICW  QUARTCRLY 
GUIDELINES  FOR  CONTRIBUTORS 


The  Acquisition  Review  Quarterly 
(ARQ)  is  a  scholarly  peer-reviewed  jour¬ 
nal  published  by  the  Defense  Acquisition 
University.  All  submissions  receive  a 
masked  review  to  ensure  impartial  evalu¬ 
ation. 


Submissions 


Submissions  are  welcomed  from  any¬ 
one  involved  in  the  Defense  acquisition 
process.  Defense  acquisition  is  defined  as 
the  conceptualization,  initiation,  design, 
development,  test,  contracting,  produc¬ 
tion,  deployment,  logistic  support,  modi¬ 
fication,  and  disposal  of  weapons  and 
other  systems,  supplies,  or  services  to  sat¬ 
isfy  Defense  Department  needs,  or  in¬ 
tended  for  use  in  support  of  military  mis¬ 
sions. 


Research  Articles 


Manuscripts  should  reflect  research  or 
empirically-supported  experience  in  one 
or  more  of  the  aforementioned  areas  of 
acquisition.  Research  or  tutorial  articles 
should  not  exceed  4,500  words.  Opinion 
pieces  should  be  limited  to  1,500  words. 

We  publish  Defense  Acquisition  re¬ 
search  articles  that  involve  systemic  in¬ 


quiry  into  a  significant  research  question. 
The  article  must  produce  a  new  or  revised 
theory  of  interest  to  the  acquisition  com¬ 
munity.  You  must  use  a  reliable,  valid  in¬ 
strument  to  provide  your  measured  out¬ 
comes. 


Manuscript  Sections 


The  introduction  should  state  the  pur¬ 
pose  of  the  article  and  concisely  summa¬ 
rize  the  rationale  for  the  undertaking. 

The  methods  section  should  include  a 
detailed  methodology  that  clearly  de¬ 
scribes  work  performed.  Although  it  is 
appropriate  to  refer  to  previous  publica¬ 
tions  in  this  section,  the  author  should  pro¬ 
vide  enough  information  so  that  the  expe¬ 
rienced  reader  need  not  read  earlier  works 
to  gain  understanding  of  the  methodology. 

The  results  section  should  concisely 
summarize  findings  of  the  research  and 
follow  the  train  of  thought  established  in 
the  methods  section.  This  section  should 
not  refer  to  previous  publications,  but 
should  be  devoted  solely  to  the  current 
findings  of  the  author. 

The  discussion  section  should  empha¬ 
size  the  major  findings  of  the  study  and 
its  significance.  Information  presented  in 
the  aforementioned  sections  should  not  be 
repeated. 
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Research  Considerations 


Contributors  should  also  consider  the 
following  questions  in  reviewing  their  re¬ 
search-based  articles  prior  to  submission: 

•  Is  the  research  question  significant? 

•  Are  research  instruments  reliable  and 
valid? 

•  Are  outcomes  measured  in  a  way 
clearly  related  to  the  variables  under 
study? 

•  Does  the  research  design  fully  and  un¬ 
ambiguously  test  the  hypothesis? 

•  Did  you  build  needed  controls  into  the 
study? 

Contributors  of  research-based  submis¬ 
sions  are  also  reminded  they  should  share 
any  materials  and  methodology  necessary 
to  verify  their  conclusions. 

Criteria  for  Tutorials 


Tutorials  should  provide  special  in¬ 
struction  or  knowledge  relevant  to  an  area 
of  defense  acquisition  to  inform  the  De¬ 
fense  Acquisition  Workforce. 

Topics  for  submissions  should  rely  on 
or  be  derived  from  observation  or  experi¬ 
ment,  rather  than  theory.  The  submission 
should  provide  knowledge  in  a  particular 
area  for  a  particular  purpose. 


Opinion  Criteria 


Opinion  articles  should  reflect  judg¬ 
ments  based  on  the  special  knowledge  of 
the  expert.  Opinion  articles  should  be 
based  on  observable  phenomena  and  pre¬ 
sented  in  a  factual  manner;  that  is,  sub¬ 
missions  should  imply  detachment.  The 
observation  and  judgment  should  not  re¬ 
flect  the  author’s  personal  feelings  or 
thoughts.  Nevertheless,  opinion  pieces 
should  clearly  express  a  fresh  point  of 
view,  rather  than  negatively  criticize  the 
view  of  another  previous  author. 


Manuscript  Style 


We  will  require  you  to  recast  your  last 
version  of  the  manuscript,  especially  ci¬ 
tations  (e.g.,  footnotes  or  endnotes)  into 
the  format  required  in  two  specific  style 
manuals.  The  ARQ  follows  the  author 
(date)  form  of  citation.  We  expect  you  to 
use  the  Publication  Manual  of  the  Ameri¬ 
can  Psychological  Association  (4th  Edi¬ 
tion),  and  the  Chicago  Manual  of  Style 
(14th  Edition).  The  ARQ  follows  the  au¬ 
thor  (date)  form  of  citation. 

Contributors  are  encouraged  to  seek  the 
advice  of  a  reference  librarian  in  complet¬ 
ing  citations  of  government  documents. 
Standard  formulas  of  citations  may  give 
only  incomplete  information  in  reference 
to  government  works.  Helpful  guidance 
is  also  available  in  Gamer,  D.L.  and  Smith, 
D.H.,  1993,  The  Complete  Guide  to  Cit¬ 
ing  Government  Documents:  A  Manual 
for  Writers  and  Librarians  (Rev.  Ed.), 
Bethesda,  MD:  Congressional  Informa¬ 
tion  Service,  Inc. 
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Guidelines  for  Contributors 


Copyright  Information 


The  ARQ  is  a  publication  of  the  United 
States  Government  and  as  such  is  not 
copyrighted.  Contributors  of  copyrighted 
works  and  copyright  holders  of  works  for 
hire  are  strongly  encouraged  to  request 
that  a  copyright  notification  be  placed  on 
their  published  work  as  a  safeguard  against 
unintentional  infringement.  The  work  of 
federal  employees  undertaken  as  part  of 
their  official  duties  is  not  subject  to  copy¬ 
right. 

In  citing  the  work  of  others,  it  is  the 
contributor’s  responsibility  to  obtain  per¬ 
mission  from  a  copyright  holder  if  the  pro¬ 
posed  use  exceeds  the  fair  use  provisions 
of  the  law  (see  U.S.  Government  Printing 
Office,  1994,  Circular  92:  Copyright  Law 
of  the  United  States  of  America,  p.  15, 
Washington,  DC:  Author).  Contributors 
will  be  required  to  submit  a  copy  of  the 
written  permission  to  the  editor  before 
publication. 


Manuscript  Format 


Pages  should  be  double-spaced  and  or¬ 
ganized  in  the  following  order:  title  page, 
abstract,  body,  reference  list,  author’s  note 
(if  any),  and  figures  or  tables.  To  ensure 
anonymity,  each  paper  should  be  submit¬ 
ted  with  a  separate  page  that  includes  the 
author(s)’s  name(s)  and  complete  address, 
and  the  paper  should  include  the  title,  ab¬ 
stract,  keywords,  body,  complete  set  of 
references,  along  with  tables  and  figures 
at  the  end.  Authors  are  reminded  not  to 
refer  to  themselves  or  to  their  own  work 
directly  in  the  paper.  Figures  or  tables 
should  not  be  inserted  (or  embedded,  etc.) 


into  the  text,  but  segregated  one  to  a  page 
following  the  text.  Articles  must  be  print¬ 
able  within  one  issue  and  should  not  ex¬ 
ceed  4,500  words  for  research  or  tutorials 
and  1,500  words  for  opinion  pieces;  ar¬ 
ticles  will  not  be  printed  in  parts  or  in  a 
continuing  series.  If  material  is  submitted 
on  a  computer  diskette,  each  figure  or  table 
should  be  recorded  in  a  separate,  export¬ 
able  file  (i.e.,  a  readable  .eps  file).  For 
additional  information  on  the  preparation 
of  figures  or  tables,  see  CBE  Scientific 
Illustration  Committee,  1988,  Illustrating 
Science:  Standards  for  Publication, 
Bethesda,  MD:  Council  of  Biology  Edi¬ 
tors,  Inc.  Please  restructure  briefing  charts 
and  slides  to  a  look  similar  to  those  in  pre¬ 
vious  issues  of  ARQ. 

The  author  (or  corresponding  author  in 
the  case  of  multiple  authorship)  should 
attach  to  the  manuscript  a  signed  cover 
letter  that  provides  the  author’s  name,  ad¬ 
dress,  and  telephone  number  (fax  and 
Internet  addresses  are  also  appreciated). 
The  letter  should  verify  that  the  submis¬ 
sion  is  an  original  product  of  the  author; 
that  it  has  not  been  published  before;  and 
that  it  is  not  under  consideration  by  an¬ 
other  publication.  Details  about  the  manu¬ 
script  should  also  be  included  in  this  let¬ 
ter:  for  example,  its  title,  word  length,  the 
need  for  copyright  notification,  the  iden¬ 
tification  of  copyrighted  material  for 
which  permission  must  be  obtained,  a  de¬ 
scription  of  the  computer  application  pro¬ 
grams  and  file  names  used  on  enclosed 
diskettes,  etc. 

The  letter,  one  copy  of  the  printed 
manuscript,  and  any  diskettes  should  be 
sturdily  packaged  and  mailed  to:  Defense 
Systems  Management  College,  Attn: 
DSMC  Press  (ARQ),  9820  Belvoir  Road, 
Suite  3,  Fort  Belvoir,  VA  22060-5565. 
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In  most  cases,  the  author  will  be  noti¬ 
fied  that  the  submission  has  been  received 
within  48  hours  of  its  arrival.  Following 
an  initial  review,  submissions  will  be  re¬ 
ferred  to  referees  and  subsequent  consid¬ 
eration  by  the  ARQ  Editorial  Board. 

Contributors  may  direct  their  questions 
to  the  Editor,  ARQ ,  at  the  address  shown 


above,  by  calling  (703)  805-4290  (fax 
805-  2917),  or  via  the  Internet  at: 
gonzalezd@dsmc.dsm.mil. 

The  DSMC  Home  Page  can  be  accessed 
at: 

http://www.dsmc.dsm.mil. 
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DSMC'S  Home  Page 

http://www.dsmc.dsm.mil 


Your  Online  Access  to  Acquisition  Research,  Consulting, 
Information,  and  Course  Offerings 


On  DSMC  Home  Page  Now... 


About  DSMC 

•  Commandant's  Welcome 

•  DSMC  Information 

•  Executive  Institute 

•  DSMC  Education 

•  General  Student  Information 

•  Getting  to  Ft.  Belvoir 

•  News  and  Events 

Research 

•  David  D.  Acker  Library 

•  Acquisition  Related  Events 

•  Best  Practices 

•  Lessons  Learned 

•  Overview/Projects 

•  ROAR 

•  Information  Dissemination 

•  Related  Links 

•  Publications 

•  Services 


Education 

•  Academic  Programs  Division 

•  Course  Catalog 

•  Division  of  College  Administration  and 

Services  (DCAS) 

•  Divisions/Faculty  Departments 

•  DSMC  Alumni 

•  DSMC  Course  List 

•  The  Executive  Program  Manager's 

Course  (EPMC) 

•  Access  to  the  EPMC  Intranet 

•  Learning  Resource  Center 

•  Program  Management 

•  Regional  Centers 

•  Registrar 

Consulting 

•  The  Cost  Analysis  Strategy  Assessment 

(CASA)  model 

•  Expertise  List 

•  Management  Deliberation  Center 

(MDC)/Group  Services 

•  Consulting  Services 


Now  you  can  Search  the  DSMC  Website  and  our  on-line  Publications! 
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PROGRAM  MANAGER  SUBSCRIPTION 


order  processing  code:  Superintendent  of  Documents  charge  your  order. 

*5456  Subscription  Order  Form  ^  tfs  ea*y!  1  ■■■■ 

To  fax  your  orders  (202)  51 2-2250 

□YES,  please  send  me _ subscription(s)  to  the  Program  Manager,  Journal  of  the  Defense  Systems 

Management  College,  (PROM)  at  $14.00  each  per  year. 

The  total  cost  of  my  order  is  $ _ .  Price  includes  For  privacy,  check  box  below: 

regular  shipping  and  handling  and  is  subject  to  change.  □  q0  not  make  my  name  available  to  other  mailers 

International  customers,  please  add  25%.  ..  .  . 


Superintendent  of  Documents 
Subscription  Order  Form 


Company  or  personal  name 


Additional  address/attention  line 


Street  address 


City,  State,  Zip  code 


Daytime  phone  including  area  code 


Purchase  order  number  (optional) 

C]  Change  of  address  only. 


(Please  type  or  print) 


For  privacy,  check  box  below: 

□  Do  not  make  my  name  available  to  other  mailers 
Check  method  of  payment: 

□  Check  payable  to  Superintendent  of  Documents 

□  GPO  Deposit  Account  L1JJ..J.JL...LJ  ““  LJ 

□  VISA  □  MasterCard  L.L..LJ . 1  (expiration  date) 


Thank  you  for  your  order! 


Authorizing  Signature  1/96 

Mail  to:  Superintendent  of  Documents 

P.O.  Box  371954,  Pittsburgh,  PA  15250-7954 


FREE  SUBSCRIPTIONS 


ACQUISITION  REVIEW  QUARTERLY  (ARQ) 

I  I  Change  of  address  only. 

[I]  Please  add  my  name  to  your  free  subscription  list. 


o 

> 


FEDERAL  EMPLOYEES  Can  Receive  a  Free  Subscription  to 

PROGRAM  MANAGER  (PM)  and/or 
ACQUISITION  REVIEW  QUARTERLY  (ARQ) 

I  am  a  federal  employee  (military  or  civilian)  and  want  to  add  my  name  to  your  free  subscription  list. 


PM  □ 
ARQ  □ 
BOTH  □ 
Change  of  address  only  □ 


Name  and  Title 


Organization 


Address 

. ( . ) . 

City  State  Zip  Daytime  Phone 
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AFFIX 

POSTAGE 

HERE 


SUPERINTENDENT  OF  DOCUMENTS 
P.O.  BOX  371 954 
PITTSBURGH,  PA  15250-7954 


BUSINESS  REPLY  MAIL 

FIRST  CLASS  PERMIT  NO.  12  FORT  BELVOIR,  VA 


POSTAGE  WILL  BE  PAID  BY  ADDRESSEE 

DEPARTMENT  OF  DEFENSE 
DEFENSE  SYST  MGMT  COLLEGE 
ATTN  DSMC  PRESS 
9820  BELVOIR  ROAD 
SUITE  3 

FT  BELVOIR  VA  22060-9989 


NO  POSTAGE 
NECESSARY 
IF  MAILED 
IN  THE 

UNITED  STATES 
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BUSINESS  REPLY  MAIL 

FIRST  CLASS  PERMIT  NO.  12  FORT  BELVOIR,  VA 


POSTAGE  WILL  BE  PAID  BY  ADDRESSEE 

DEPARTMENT  OF  DEFENSE 
DEFENSE  SYST  MGMT  COLLEGE 
ATTN  DSMC  PRESS 
9820  BELVOIR  ROAD 
SUITE  3 

FT  BELVOIR  VA  22060-9989 


NO  POSTAGE 
NECESSARY 
IF  MAILED 
IN  THE 

UNITED  STATES 


IiiI,I„IiIII.ii.II..IIiiiIiIiiI>Ii'Ii'I'I'I'"IiI'I 


RENEW  ARQ  NOW! 

The  U.S.  postal  regulations  require  that  if  you  receive  a  free  subscription 
for  ARQ,  and  wish  to  continue  doing  so,  you  must  sign,  date  and  return 
this  form  no  later  than  May  30, 1999.  Also,  please  answer  a  few  questions. 
Remove  the  pressure-sensitive  label  from  the  publication's  cover  and  place 
it  on  the  form's  designated  spot.  Make  address  corrections  directly  on  the 
label.  After  signing,  dating,  and  providing  information,  fold  the  form  so  the 
business  reply's  mailing  address  is  visible;  tape  it  closed  (PLEASE  DO  NOT 
STAPLE),  and  drop  it  in  the  mail  or  fax  it  to  (703)  805-2917.  If  you  do  not 
respond,  you  will  be  dropped  from  our  mailing  list.  This  update  will  keep 
your  subscription  current  through  May  2002. 

YES!  I  (or  my  office)  would  like  to  continue  receiving  the 
Acquisition  Review  Quarterly. 


(Signature  and  Date) 


PLEASE  PLACE  ADDRESS  LABEL  HERE 


STATUS  (OFFICE  OR  INDIVIDUAL),  CHECK  ONE: 


DoD  Civilian  Military 


□  OSD 

□  Army 

□  Navy 

□  Air  Force 

□  Marine  Corps 


□  Army 

□  Navy 

□  Air  Force 

□  Marine  Corps 

□  Non-DoD  Government 


Other 

□  Industry 

□  Academia 

□  Library  (Ind.,  Acad.,  Govt.) 

□  Complimentary 

□  Other 


DSMC  GRADUATES  PLEASE  CHECK  APPROPRIATE  BOX(ES): 

(Use  course  #  or  acronym) 

□  PMC/APMC  Class _ (ex.,  APMC  98-1) 

□  Executive  Course(s) _ (ex.,  EPMC  98-1) 

□  Short  Course(s) _ (ex.,  ACQ101  98-1) 
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